Personalized medicine system

ABSTRACT

A method, program storage device and system for developing a Personalized Medicine System ( 100 ) for an individual or group of individuals that automates the operation, customization and coordination of computer systems, software, products, services, data and/or devices.

CONTINUATION, CONTINUATION IN PART AND RELATED PROVISIONAL APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/094,171 filed Mar. 31, 2005 and a continuation in part of U.S. patentapplication Ser. No. 10/717,026 filed on Nov. 19, 2003 the disclosuresof which are both incorporated herein by reference. application Ser. No.11/094,171 is a continuation in part of U.S. Patent application Ser. No.10/717,026 and a non provisional application of U.S. Provisional Patentapplication No. 60/566,614 filed on April 29, 2004 the disclosure ofwhich is also incorporated herein by reference. application Ser. No.10/717,026 claimed priority from provisional application No. 60/432,283filed on Dec. 10, 2002 and provisional application No. 60/464,837 filedon Apr. 23, 2003 the disclosures of which are also incorporated hereinby reference.

BACKGROUND OF THE INVENTION

This invention relates to methods, program storage devices and systemsfor developing a Personalized Medicine System (100) for an individual orgroup of individuals that can support the operation, customization andcoordination of computer systems, software, products, services, data,entities and/or devices.

SUMMARY OF THE INVENTION

It is a general object of the present invention to provide a novel,useful system that develops and maintains one or more individual and/orgroup contexts in a systematic fashion and uses the one or more contextsto develop a Personalized Medicine System (100) that supports theoperation and coordination of software including a Complete Context™Suite of services (625), a Complete Context™ Development System (610)and a plurality of Complete Context™ Bots (650), one or more externalservices (9), one or more narrow systems (4), entities and/or one ormore devices (3).

The innovative system of the present invention supports the developmentand integration of any combination of data, information and knowledgefrom systems that analyze, monitor, support and/or are associated withentities in three distinct areas: a social environment area (1000), anatural environment area (2000) and a physical environment area (3000).Each of these three areas can be further subdivided into domains. Eachdomain can in turn be divided into a hierarchy or group. Each member ofa hierarchy or group is a type of entity.

The social environment area (1000) includes a political domain hierarchy(1100), a habitat domain hierarchy (1200), an intangibles domain group(1300), an interpersonal domain group (1400), a market domain hierarchy(1500) and an organization domain hierarchy (1600). The political domainhierarchy (1100) includes a voter entity type (1101), a precinct entitytype (1102), a caucus entity type (1103), a city entity type (1104), acounty entity type (1105), a state/province entity type (1106), aregional entity type (1107), a national entity type (1108), amulti-national entity type (1109) and a global entity type (1110). Thehabitat domain hierarchy includes a household entity type (1202), aneighborhood entity type (1203), a community entity type (1204), a cityentity type (1205) and a region entity type (1206). The intangiblesdomain group (1300) includes a brand entity type (1301), an expectationsentity type (1302), an ideas entity type (1303), an ideology entity type(1304), a knowledge entity type (1305), a law entity type (1306), aintangible asset entity type (1307), a right entity type (1308), arelationship entity type (1309), a service entity type (1310) and asecurities entity type (1311). The interpersonal group includes (1400)includes an individual entity type (1401), a nuclear family entity type(1402), an extended family entity type (1403), a clan entity type(1404), an ethnic group entity type (1405), a neighbors entity type(1406) and a friends entity type (1407). The market domain hierarchy(1500) includes a multi entity type organization entity type (1502), anindustry entity type (1503), a market entity type (1504) and an economyentity type (1505). The organization domain hierarchy (1600) includesteam entity type (1602), a group entity type (1603), a department entitytype (1604), a division entity type (1605), a company entity type (1606)and an organization entity type (1607). These relationships aresummarized in Table 1.

TABLE 1 Social Environment Domains Members (lowest level to highest forhierarchies) Political (1100) voter (1101), precinct (1102), caucus(1103), city (1104), county (1105), state/province (1106), regional(1107), national (1108), multi-national (1109), global (1110) Habitat(1200) household (1202), neighborhood (1203), community (1204), city(1205), region (1206) Intangibles Group (1300) brand (1301),expectations (1302), ideas (1303), ideology (1304), knowledge (1305),law (1306), intangible assets (1307), right (1308), relationship (1309),service (1310), securities (1311) Interpersonal Group (1400) individual(1401), nuclear family (1402), extended family (1403), clan (1404),ethnic group (1405), neighbors (1406), friends (1407) Market (1500)multi-entity organization (1502), industry (1503), market (1504),economy (1505) Organization (1600) team (1602), group (1603), department(1604), division (1605), company (1606), organization (1607)

The natural environment area (2000) includes a biology domain hierarchy(2100), a cellular domain hierarchy (2200), an organism domain hierarchy(2300) and a protein domain hierarchy (2400) as shown in Table 2. Thebiology domain hierarchy (2100) contains a species entity type (2101), agenus entity type (2102), a family entity type (2103), an order entitytype (2104), a class entity type (2105), a phylum entity type (2106) anda kingdom entity type (2107). The cellular domain hierarchy (2200)includes a macromolecular complexes entity type (2202), a protein entitytype (2203), a rna entity type (2204), a dna entity type (2205), anx-ylation** entity type (2206), an organelles entity type (2207) andcells entity type (2208). The organism domain hierarchy (2300) containsa structures entity type (2301), an organs entity type (2302), a systemsentity type (2303) and an organism entity type (2304). The proteindomain hierarchy contains a monomer entity type (2400), a dimer entitytype (2401), a large oligomer entity type (2402), an aggregate entitytype (2403) and a particle entity type (2404). These relationships aresummarized in Table 2.

TABLE 2 Natural Environment Domains Members (lowest level to highest forhierarchies) Biology (2100) species (2101), genus (2102), family (2103),order (2104), class (2105), phylum (2106), kingdom (2107) Cellular*(2200) macromolecular complexes (2202), protein (2203), rna (2204), dna(2205), x-ylation** (2206), organelles (2207), cells (2208) Organism(2300) structures (2301), organs (2302), systems (2303), organism (2304)Protein (2400) monomer (2400), dimer (2401), large oligomer (2402),aggregate (2403), particle (2404) *includes viruses **x = methyl,phosphor, etc.The physical environment area (3000) contains a chemistry group (3100),a geology domain hierarchy (3200), a physics domain hierarchy (3300), aspace domain hierarchy (3400), a tangible goods domain hierarchy (3500),a water group (3600) and a weather group (3700) as shown in Table 3. Thechemistry group (3100) contains a molecules entity type (3101), acompounds entity type (3102), a chemicals entity type (3103) and acatalysts entity type (3104). The geology domain hierarch contains aminerals entity type (3202), a sediment entity type (3203), a rockentity type (3204), a landform entity type (3205), a plate entity type(3206), a continent entity type (3207) and a planet entity type (3208).The physics domain hierarchy (3300) contains a quark entity type (3301),a particle zoo entity type (3302), a protons entity type (3303), aneutrons entity type (3304), an electrons entity type (3305), an atomsentity type (3306), and a molecules entity type (3307). The space domainhierarchy contains a dark matter entity type (3402), an asteroids entitytype (3403), a comets entity type (3404), a planets entity type (3405),a stars entity type (3406), a solar system entity type (3407), a galaxyentity type (3408) and universe entity type (3409). The tangible goodshierarchy contains a money entity type (3501), a compounds entity type(3502), a minerals entity type (3503), a components entity type (3504),a subassemblies entity type (3505), an assembly's entity type (3506), asubsystems entity type (3507), a goods entity type (3508) and a systemsentity type (3509). The water group (3600) contains a pond entity type(3602), a lake entity type (3603), a bay entity type (3604), a seaentity type (3605), an ocean entity type (3606), a creek entity type(3607), a stream entity type (3608), a river entity type (3609) and acurrent entity type (3610). The weather group (3700) contains anatmosphere entity type (3701), a clouds entity type (3702), a lightningentity type (3703), a precipitation entity type (3704), a storm entitytype (3705) and a wind entity type (3706).

TABLE 3 Physical Environment Domains Members (lowest level to highestfor hierarchies) Chemistry Group (3100) molecules (3101), compounds(3102), chemicals (3103), catalysts (3104) Geology (3200) minerals(3202), sediment (3203), rock (3204), landform (3205), plate (3206),continent (3207), planet (3208) Physics (3300) quark (3301), particlezoo (3302), protons (3303), neutrons (3304), electrons (3305), atoms(3306), molecules (3307) Space (3400) dark matter (3402), asteroids(3403), comets (3404), planets (3405), stars (3406), solar system(3407), galaxy (3408), universe (3409) Tangible Goods (3500) money(3501), compounds (3502), minerals (3503), components (3504),subassemblies (3505), assemblies (3506), subsystems (3507), goods(3508), systems (3509) Water Group (3600) pond (3602), lake (3603), bay(3604), sea (3605), ocean (3606), creek (3607), stream (3608), river(3609), current (3610) Weather Group (3700) atmosphere (3701), clouds(3702), lightning (3703), precipitation (3704), storm (3705), wind(3706)Individual entities are items of one or more entity type. The analysisof the health of an individual or group can be linked together with aplurality of different entities to support an analysis that extendsacross several domains. Entities and patients can also be linkedtogether to follow a chain of events that impacts one or more patientsand/or entities. These chains can be recursive. The domain hierarchiesand groups shown in Tables 1, 2 and 3 can be organized into differentareas and they can also be expanded, modified, extended or pruned inorder to support different analyses.

Data, information and knowledge from these seventeen different domainscan be integrated and analyzed in order to support the creation of oneor more health contexts for the subject individual or group. The one ormore contexts developed by this system focus on the function performance(note the terms behavior and function performance will be usedinterchangeably) of a single patient as shown in FIG. 2A, a group of twoor more patients as shown in FIG. 2B and/or a patient-entity system inone or more domains as shown in FIG. 2C. FIG. 2A shows an entity (900)and a function impact network diagram for a location (901), a project(902), an event (903), a virtual location (904), a factor (905), aresource (906), an element (907), an action/transaction (908/909), afunction measure (910), a process (911), a subject mission (912),constraint (913) and a preference (914). FIG. 2B shows a collaboration(925) between two entities and the function impact network diagram forlocations (901), projects (902), events (903), virtual locations (904),factors (905), resources (906), elements (907), action/transactions(908/909), a joint measure (915), processes (911), a joint mission(916), constraints (913) and preferences (914). For simplicity we willhereinafter use the terms patient or subject with the understanding thatthey refer to a patient (900) as shown in FIG. 2A, a group of two ormore patients (925) as shown in FIG. 2B or a patient-entity system (950)as shown in FIG. 2C. While only two entities are shown in FIG. 2B andFIG. 2C it is to be understood that the subject can contain more thantwo patients and/or entities.

After one or more contexts are developed for the subject, they can becombined, reviewed, analyzed and/or applied using one or more of thecontext-aware services in a Complete Context™ Suite (625) of services.These services are optionally modified to meet user requirements using aComplete Context™ Development System (610). The Complete Context™Development System (610) supports the maintenance of the services in theComplete Context™ Suite (625), the creation of newly defined stand-aloneservices, the development of new services and/or the programming ofcontext-aware bots.

The system of the present invention systematically develops the one ormore complete contexts for distribution in a Personalized MedicineSystem (100). These contexts are in turn used to support thecomprehensive analysis of subject performance, develop one or moreshared contexts to support collaboration, simulate subject performanceand/or turn data into knowledge. Processing in the Personalized MedicineSystem (100) is completed in three steps:

-   -   1. subject definition and measure specification;    -   2. context and contextbase (50) development, and    -   3. Complete Context™ service development and distribution.        The first processing step in the Personalized Medicine System        (100) defines the subject that will be analyzed, prepares the        data from devices (3), entity narrow system databases (5),        partner narrow system databases (6), external databases (7), the        World Wide Web (8), external services (9) and/or the Complete        Context™ Input System (601) for use in processing and then uses        these data to specify subject functions as well as function        and/or mission measures.

As part of the first stage of processing, the user (40) identifies thesubject by using existing hierarchies and groups, adding a new hierarchyor group or modifying the existing hierarchies and/or groups in order tofully define the subject. As discussed previously, each subjectcomprises one of three types. These definitions can be supplemented byidentifying actions, constraints, elements, events, factors,preferences, processes, projects, risks and resources that impact thesubject. For example, a white blood cell entity is an item with the cellentity type (2208) and an element of the circulatory system andauto-immune system (2303). In a similar fashion, entity Jane Doe couldbe an item within the organism entity type (2300), an item within thevoter entity type (1101), an element of a team entity (1602), an elementof a nuclear family entity (1402), an element of an extended familyentity (1403) and an element of a household entity (1202). Thisindividual would be expected to have one or more functions and functionand/or mission measures for each entity type she is associated with.Separate systems that tried to analyze the six different roles of theindividual in each of the six hierarchies would probably save some ofthe same data six separate times and use the same data in six differentways. At the same time, all of the work to create these six separatesystems might provide very little insight because the complete contextfor behavior of this subject at any one period in time is a blend of thecontext associated with each of the six different functions she issimultaneously performing in the different domains. Predefined templatesfor the different entity types can be used at this point to facilitatethe specification of the subject (these same templates can be used toaccelerate learning by the system of the present invention). Thisspecification can include an identification of other subjects that arerelated to the entity. For example, the individual could identity herfriends, family, home, place of work, church, car, typical foods,hobbies, favorite malls, etc. using one of these predefined templates.The user could also indicate the level of impact of each of theseentities has on different function and/or mission measures. Theseweightings can in turn be verified by the system of the presentinvention.

After the subject definition is completed, structured data andinformation, transaction data and information, descriptive data andinformation, unstructured data and information, text data andinformation, geo-spatial data and information, image data andinformation, array data and information, web data and information, videodata and video information, device data and information, and/or servicedata and information are made available for analysis by converting dataformats before mapping these data to a contextbase (50) in accordancewith a common schema or ontology. The automated conversion and mappingof data and information from the existing devices (3) narrowcomputer-based system databases (5 & 6), external databases (7), theWorld Wide Web (8) and external services (9) to a common schema orontology significantly increases the scale and scope of the analysesthat can be completed by users. This innovation also gives users (40)the option to extend the life of their existing narrow systems (4) thatwould otherwise become obsolete. The uncertainty associated with thedata from the different systems is evaluated at the time of integration.Before going further, it should be noted that the Personalized MedicineSystem (100) is also capable of operating without completing some or allnarrow system database (5 & 6) conversions and integrations as it candirectly accept data that complies with the common schema or ontology.The Personalized Medicine System (100) is also capable of operatingwithout any input from narrow systems (4). For example, the CompleteContext™ Input Service (601) (and any other application capable ofproducing xml documents) is fully capable of providing all data directlyto the Personalized Medicine System (100).

The Personalized Medicine System (100) supports the preparation and useof data, information and/or knowledge from the “narrow” systems (4)listed in Tables 4, 5, 6 and 7 and devices (3) listed in Table 8.

TABLE 4 Biomedical affinity chip analyzer, array systems, biochipsystems, bioinformatic Systems systems, biological simulation systems,blood chemistry systems, blood pressure systems, body sensors, clinicalmanagement systems, diagnostic imaging systems, electronic patientrecord systems, electrophoresis systems, electronic medicationmanagement systems, enterprise appointment scheduling, enterprisepractice management, fluorescence systems, formulary management systems,functional genomic systems, galvanic skin sensors, gene chip analysissystems, gene expression analysis systems, gene sequencers, glucose testequipment, information based medical systems, laboratory informationmanagement systems, liquid chromatography, mass spectrometer systems,microarray systems, medical testing systems, microfluidic systems,molecular diagnostic systems, nano-string systems, nano-wire systems,peptide mapping systems, pharmacoeconomic systems, pharmacogenomic datasystems, pharmacy management systems, practice management systems,protein biochip analysis systems, protein mining systems, proteinmodeling systems, protein sedimentation systems, protein sequencer,protein visualization systems, proteomic data systems, stentennas,structural biology systems, systems biology applications, x*-ylationanalysis systems *x = methyl, phosphor,

TABLE 5 Personal appliance management systems, automobile managementsystems, blogs, Systems contact management applications, creditmonitoring systems, gps applications, home management systems, imagearchiving applications, image management applications, folksonomies,lifeblogs, media archiving applications, media applications, mediamanagement applications, personal finance applications, personalproductivity applications (word processing, spreadsheet, presentation,etc.), personal database applications, personal and group schedulingapplications, social networking applications, tags, video applications

TABLE 6 Scientific accelerometers, atmospheric survey systems,geological Systems survey systems, ocean sensor systems, seismographicsystems, sensors, sensor grids, sensor networks, smart dust

TABLE 7 Management accounting systems**, advanced financial systems,alliance management Systems systems, asset and liability managementsystems, asset management systems, battlefield systems, behavioral riskmanagement systems, benefits administration systems, brand managementsystems, budgeting/financial planning systems, building managementsystems, business intelligence systems, call management systems, cashmanagement systems, channel management systems, claims managementsystems, command systems, commodity risk management systems, contentmanagement systems, contract management systems, credit-risk managementsystems, customer relationship management systems, data integrationsystems, data mining systems, demand chain systems, decision supportsystems, device management systems document management systems, emailmanagement systems, employee relationship management systems, energyrisk management systems, expense report processing systems, fleetmanagement systems, foreign exchange risk management systems, fraudmanagement systems, freight management systems, geological surveysystems, human capital management systems, human resource managementsystems, incentive management systems, information lifecycle managementsystems, information technology management systems, innovationmanagement systems, instant messaging systems, insurance managementsystems, intellectual property management systems, intelligent storagesystems, interest rate risk management systems, investor relationshipmanagement systems, knowledge management systems, litigation trackingsystems, location management systems, maintenance management systems,manufacturing execution systems, material requirement planning systems,metrics creation system, online analytical processing systems, ontologysystems, partner relationship management systems, payroll systems,performance dashboards, performance management systems, priceoptimization systems, private exchanges, process management systems,product life- cycle management systems, project management systems,project portfolio management systems, revenue management systems, riskmanagement information systems, sales force automation systems,scorecard systems, sensors (includes RFID), sensor grids (includesRFID), service management systems, simulation systems, six-sigma qualitymanagement systems, shop floor control systems, strategic planningsystems, supply chain systems, supplier relationship management systems,support chain systems, system management applications, taxonomy systems,technology chain systems, treasury management systems, underwritingsystems, unstructured data management systems, visitor (web site)relationship management systems, weather risk management systems,workforce management systems, yield management systems and combinationsthereof **these typically include an accounts payable system, accountsreceivable system, inventory system, invoicing system, payroll systemand purchasing system

TABLE 8 Devices personal digital assistants, phones, watches, clocks,lab equipment, personal computers, televisions, radios, personalfabricators, personal health monitors, refrigerators, washers, dryers,ovens, lighting controls, alarm systems, security systems, hvac systems,gps devices, smart clothing (aka clothing with sensors), personalbiomedical monitoring devices, personal computersAfter data conversions have been identified the user (40) is asked tospecify entity functions. The user can select from pre-defined functionsfor each subject or define new functions using narrow system data.Examples of predefined subject functions are shown in Table 9.

TABLE 9 Entity type Example Functions Organism reproduction, killinggerms, maintaining blood sugar levels (2300)Pre-defined quantitative measures can be used if pre-defined functionswere used in defining the entity. Alternatively, new measures can becreated using narrow system data for one or more subjects and/or thePersonalized Medicine System (100) can identify the best fit measuresfor the specified functions. The quantitative measures can take anyform. For example, Table 10 shows three measures for a medicalorganization entity—patient element health, patient element longevityand organization financial break even. The Personalized Medicine System(100) incorporates the ability to use other pre-defined measuresincluding each of the different types of risk—alone or in combination—aswell as sustainability.

After the data integration, subject definition and measure specificationare completed, processing advances to the second stage where contextlayers for each subject are developed and stored in a contextbase (50).Each context for a subject can be divided into eight or more types ofcontext layers. Together, these eight layers identify: actions,constraints, elements, events, factors, preferences, processes,projects, risks, resources and terms that impact entity performance foreach function; the magnitude of the impact actions, constraints,elements, events, factors, preferences, processes, projects, risks,resources ad terms have on entity performance of each function; physicaland/or virtual coordinate systems that are relevant to entityperformance for each function and the magnitude of the impact locationrelative to physical and/or virtual coordinate systems has on entityperformance for each function. These eight layers also identify andquantify subject function and/or mission measure performance. The eighttypes of layers are:

-   -   1. A layer that defines and describes the element context over        time, i.e. we store widgets (a resource) built (an action) using        the new design (an element) with the automated lathe (another        element) in our warehouse (an element). The lathe (element) was        recently refurbished (completed action) and produces 100 widgets        per 8 hour shift (element characteristic). We can increase        production to 120 widgets per 8 hour shift if we add complete        numerical control (a feature). This layer may be subdivided into        any number of sub-layers along user specified dimensions such as        tangible elements of value, intangible elements of value,        processes, agents, assets and combinations thereof;    -   2. A layer that defines and describes the resource context over        time, i.e. producing 100 widgets (a resource) requires 8 hours        of labor (a resource), 150 amp hours of electricity (another        resource) and 5 tons of hardened steel (another resource). This        layer may be subdivided into any number of sub-layers along user        specified dimensions such as lexicon (what resources are        called), resources already delivered, resources with delivery        commitments and forecast resource requirements;    -   3. A layer that defines and describes the environment context        over time (the entities in the social (1000), natural (2000)        and/or physical environment (3000) that impact entity function        and/or mission measure performance, i.e. the volatility in the        market for steel increased 50% last year, standard deviation on        monthly shipments is 24% and analysts expect 30% growth in        revenue this quarter. This layer may be subdivided into any        number of sub-layers along user specified dimensions;    -   4. A layer that defines and describes the transaction context        (also known as tactical/administrative context) over time, i.e.        Acme owes us $30,000 for prior sales, we have made a commitment        to ship 100 widgets to Acme by Tuesday and need to start        production by Friday. This layer may be subdivided into any        number of sub-layers along user specified dimensions such as        historical transactions, committed transactions, forecast        transactions, historical events, forecast events and        combinations thereof;    -   5. A layer that defines and describes the relationship context        over time, i.e. Acme is also a key supplier for the new product        line, Widget X, that is expected to double our revenue over the        next five years. This layer may be subdivided into any number of        sub-layers along user specified dimensions;    -   6. A layer that defines and describes the measurement context        over time, i.e. the price per widget is $100 and the cost of        manufacturing widgets is $80 so we make $20 profit per unit (for        most businesses this would be a short term profit measure for        the value creation function). Also, Acme is one of our most        valuable customers and they are a valuable supplier to the        international division (value based measures). This layer may be        subdivided into any number of sub-layers along user specified        dimensions. For example, the instant, five year and lifetime        impact of certain medical treatments may be of interest. In this        instance, three separate measurement layers could be created to        provide the desired context. The risks associated with each        measure can be integrated within each measurement layer or they        can be stored in separate layers. For example, value measures        for organizations integrate the risk and the return associated        with measure performance. Measures associated with other        entities can be included in this layer. This capability enables        the use of the difference between the subject measure and the        measures of other entities as measures;    -   7. A layer that optionally defines the relationship of one or        more of the first six layers of entity context to one or more        reference systems over time. A spatial reference coordinate        system will be used for most entities. Pre-defined spatial        reference coordinates available for use in the system of the        present invention include the major organs in a human body, each        of the continents, the oceans, the earth and the solar system.        Virtual reference coordinate systems can also be used to relate        each entity to other entities. For example, a virtual coordinate        system could be a network such as the Internet, an intranet, a        local are network, a wi-fi network, a wimax network and/or        social network. The genome of different entities can also be        used as a reference coordinate system. This layer may also be        subdivided into any number of sub-layers along user specified        dimensions and would identify system or application context if        appropriate;    -   8. A layer that defines and describes the lexicon of the        subject—this layer may be broken into sub-layers to define the        lexicon associated with each of the previous context layers.        Different combinations of context layers from different subjects        and/or entities are relevant to different analyses and        decisions. For simplicity, we will generally refer to eight        types of context layers or eight context layers while        recognizing that the number of context layers can be greater or        less than eight. It is worth noting at this point that the        layers may be combined for ease of use, to facilitate processing        and/or as entity requirements dictate. Before moving on to        discuss context frames—which are defined by one or more entity        function and/or mission measures and the portion of each of the        eight context layers that impacts the one or more entity        function and/or mission measures—we need to define each context        layer in more detail. Before we can do this, we need to define        key terms that we will use in more fully defining the        Personalized Medicine System (100) of the present invention:    -   1. Entity type—any member or combination of members of a        hierarchy or group (see Tables 1, 2 and 3 for examples of        hierarchies and groups);    -   2. Entity—a discrete unit of an entity type that has one or more        functions, these functions can support the completion of a        mission;    -   3. Context—defines and describes the situation of an entity vis        a vis the drivers of subject function performance as shown in        FIG. 2A, FIG. 2B or FIG. 2C. It includes but is not limited to        the data, information and knowledge that defines and describes        the eight context layers identified previously for a valid        context space;    -   4. User context—defines and describes the users situation vis a        vis drivers of user function performance—note: user may or may        not be the subject;    -   5. Subject—patient (900), combination of patients (925) or a        patient—entity system (950) as shown in FIG. 2A, FIG. 2B or FIG.        2C respectively with one or more defined functions;    -   6. Function—behavior or performance of the subject, can include        creation, production, growth, improvement, destruction,        diminution and/or maintenance of a component of context and/or        one or more entities. Examples: maintaining body temperature at        98.6 degrees Fahrenheit, destroying cancer cells, improving        muscle tone and producing insulin;    -   7. Mission—what an entity intends to do or achieve (i.e. a        goal), functions can support the completion of an entity        mission;    -   8. Characteristic—numerical or qualitative indication of entity        status—examples: temperature, color, shape, distance weight, and        cholesterol level (descriptive data are the typical source of        data about characteristics) and the acceptable range for these        characteristics (aka a subset of constraints);    -   9. Event—something that takes place in a defined point in space        time, the events of interest are generally those that are        recorded and have an impact on the components of context and/or        measure performance of a subject and/or change the        characteristics of an entity;    -   10. Project—action or series of actions that produces one or        more lasting changes. Change can include: changes a        characteristic, changes a constraint, produces one or more new        components of context, changes one or more components of        context, and produces one or more new entities or some        combination thereof. Said changes impact entity function        performance/mission and are analyzed using same method, system        and media described for event and extreme event analysis;    -   11. Action—acquisition, consumption, destruction, production or        transfer of resources, elements and/or entities in a defined        point in space time—examples: blood cells transfer oxygen to        muscle cells and an assembly line builds a product. Actions are        a subset of events and are generally completed by a process;    -   12. Data—anything that is recorded—includes transaction data,        descriptive data, content, information and knowledge;    -   13. Information—data with context of unknown completeness;    -   14. Knowledge—data with the associated complete context—all        eight types of layers are defined and complete to the extent        possible given uncertainty;    -   15. Transaction—anything that is recorded that isn't descriptive        data. Transactions generally reflect events and/or actions for        one or more entities over time (transaction data are generally        the source);    -   16. Measure—quantitative indication of one or more subject        functions and/or missions—examples: cash flow, patient survival        rate, bacteria destruction percentage, shear strength, torque,        cholesterol level, and pH maintained in a range between 6.5 and        7.5;    -   17. Element—also known as a context element these are tangible        and intangible entities that participate in and/or support one        or more subject actions and/or functions without normally being        consumed by the action—examples: land, heart, Sargasso sea,        relationships, wing and knowledge;    -   18. Element combination—two or more elements that share        performance drivers to the extent that they need to be analyzed        as a single element;    -   19. Item—an item is an instance within an element. For example,        an individual salesman would be an “item” within the sales        department element (or entity). In a similar fashion a gene        would be an item within a dna entity. While there are generally        a plurality of items within an element, it is possible to have        only one item within an element;    -   20. Item variables are the transaction data and descriptive data        associated with an item or related group of items;    -   21. Indicators (also known as item performance indicators and/or        factor performance indicators) are data derived from data        related to an item or a factor;    -   22. Composite variables for a context element or element        combination are mathematical combinations of item variables        and/or indicators, logical combinations of item variables and/or        indicators and combinations thereof;    -   23. Element variables or element data are the item variables,        indicators and composite variables for a specific context        element or sub-context element;    -   24. Subelement—a subset of all items in an element that share        similar characteristics;    -   25. Asset—subset of elements that support actions and are        usually not transferred to other entities and/or        consumed—examples: brands, customer relationships, information        and equipment;    -   26. Agent—subset of elements that can participate in an action.        Six distinct kinds of agents are recognized—initiator,        negotiator, closer, catalyst, regulator, messenger. A single        agent may perform several agent functions—examples: customers,        suppliers and salespeople;    -   27. Resource—entities that are routinely transferred to other        entities and/or consumed—examples: raw materials, products,        information, employee time and risks;    -   28. Subresource—a subset of all resources that share similar        characteristics;    -   29. Process—combination of elements actions and/or events that        are used to complete an action or event—examples: sales process,        cholesterol regulation and earthquake. Processes are a special        class of element;    -   30. Commitment—an obligation to complete a transaction in the        future—example: contract for future sale of products and debt;    -   31. Competitor—subset of factors, an entity that seeks to        complete the same actions as the subject, competes for elements,        competes for resources or some combination thereof;    -   32. Priority—relative importance assigned to actions and        measures;    -   33. Requirement—minimum or maximum levels for one or more        elements, element characteristics, actions, events, processes or        relationships, may be imposed by user (40), laws (1306) or        physical laws (i.e. force=mass times acceleration);    -   34. Surprise—variability or events that improve or increase        subject performance;    -   35. Risk—variability or events that reduce or degrade subject        performance;    -   36. Extreme risk—caused by variability or extreme events that        reduce subject performance by producing permanent changes in the        impact of one or more components of context on the subject;    -   37. Critical risk—extreme risks that can terminate a subject;    -   38. Competitor risk—risks that are a result of actions by an        entity that competes for resources, elements, actions or some        combination thereof;    -   39. Factor—entities external to subject that have an impact on        subject performance—examples: commodity markets, weather,        earnings expectation—as shown in FIG. 2A factors are associated        with subjects that are outside the box. All higher levels in the        hierarchy of a subject are also defined as factors.    -   40. Composite factors are numerical indicators of: external        entities that influence performance, conditions external to the        subject that influence performance, conditions of the entity        compared to external expectations of entity conditions or the        performance of the entity compared to external expectations of        entity performance;    -   41. Factor variables are the transaction data and descriptive        data associated with context factors;    -   42. Factor performance indicators (also known as indicators) are        data derived from factor related data;    -   43. Composite factors (also known as composite variables) for a        context factor or factor combination are mathematical        combinations of factor variables and/or factor performance        indicators, logical combinations of factor variables and/or        factor performance indicators and combinations thereof;    -   44. External Services (9) are services available from systems        that are not part of the system of the present invention (100)        via a network (wired or wireless) connection. They include        search services (google, yahoo!, etc.), map services (mapquest,        yahoo!, etc.), rating services (zagat's, fodor's, etc.), weather        services and services particular to a location or site        (projection services, presence detection services, voice        transcription services, traffic status reports, tour guide        information, etc.);    -   45. A layer is software and/or information that gives an        application, system, service, device or layer the ability to        interact with another layer, device, system, service,        application or set of information at a general or abstract level        rather than at a detailed level;    -   46. Context frames include all information relevant to function        measure performance for a defined combination of context layers,        subject and subject functions. In one embodiment, each context        frame is a series of pointers that are stored within a separate        table;    -   47. Complete context is a shorthand way of noting that all eight        types of context layers have been defined for an subject        function (note: it is also used as a proprietary trade-name        designation for applications or services with a context quotient        of 200);    -   48. Complete Entity Context—complete context for all entity        functions;    -   49. Components of Context—any combination of location (901),        projects (902), events (903), virtual location (904), factors        (905), resources (906, elements (907), actions (908),        transactions (909), function measures (910), processes (911),        mission measures (912), constraints (913), preferences (914) and        factors (1000, 2000 and 3000) that have a relationship to and/or        impact on a subject;    -   50. Contextbase is a database that organizes data and        information by context for one or more subject entities. In one        embodiment the contextbase is a virtual database. The        contextbase can also be a relational database, a flat database,        a storage area network and/or some combination thereof;    -   51. Total risk is the sum of all variability risks and event        risks for a subject.    -   52. Variability risk is a subset of total risk. It is the risk        of reduced or impaired performance caused by variability in one        or more components of context. Variability risk is quantified        using statistical measures like standard deviation. The        covariance and dependencies between different variability risks        are also determined because simulations use quantified        information regarding the inter-relationship between the        different risks to perform effectively;    -   53. Event risk is a subset of total risk. It is the risk of        reduced or impaired performance caused by the occurrence of an        event. Event risk is quantified by combining a forecast of event        frequency with a forecast of event impact on subject components        of context and the entity itself.    -   54. Contingent liabilities are a subset of event risk where the        impact of an event occurrence is known;    -   55. Uncertainty measures the amount of subject function measure        performance that cannot be explained by the components of        context and their associated risk that have been identified by        the system of the present invention. Sources of uncertainty        include model error and data error.    -   56. Real options are defined as options the entity may have to        make a change in its behavior/performance at some future        date—these can include the introduction of new elements or        resources, the ability to move processes to new locations, etc.        Real options are generally supported by the elements of an        entity;    -   57. The efficient frontier is the curve defined by the maximum        function and/or mission measure performance an entity can expect        for a given level of total risk; and    -   58. Services are self-contained, self-describing, modular pieces        of software that can be published, located, queried and/or        invoked across a World Wide Web, network and/or a grid. In one        embodiment all services are SOAP compliant. Bots and agents can        be functional equivalents to services. In one embodiment all        applications are services, However, the system of the present        invention can function using: bots (or agents), client server        architecture, and integrated software application architecture        and/or combinations thereof.        We will use the terms defined above and the keywords that were        defined previously when detailing one embodiment of the present        invention. In some cases key terms may be defined by the Upper        Ontology or an industry organization such as the Plant Ontology        Consortium, the Gene Ontology Consortium or the ACORD consortium        (for insurance). In a similar fashion the Global Spatial Data        Infrastructure organization and the Federal Geographic Data        Committee are defining a reference model for geographic        information that can be used to define the spatial reference        standard for geographic information. The United Nations is        similarly defining the United Nations Standard Product and        Services Classification which can also be used for reference.        The element definitions, descriptive data, lexicon and reference        frameworks from these sources can supplement or displace the        pre-defined metadata included within the contextbase (50) as        appropriate. Because the system of the present invention        identifies and quantifies the impact of different actions,        constraints, elements, events, factors, preferences, processes,        projects, risks and resources as part of its normal processing,        the relationships defined by standardized ontologies are        generally not utilized. However, they can be used as a starting        point for system processing and/or to supplement the results of        processing.

In any event, we can now use the key terms to better define the eighttypes of context layers and identify the typical source for the data andinformation as shown below.

-   -   1. The element context layer identifies and describes the        entities that impact subject function and/or mission measure        performance by time period. The element description includes the        identification of any sub-elements and preferences. Preferences        may be important characteristics for process elements that have        more than one option for completion. Elements are initially        identified by the chosen subject hierarchy (elements associated        with lower levels of a hierarchy are automatically included)        whereas transaction data identifies others as do analysis and        user input. These elements may be identified by item or        sub-element. The sources of data can include devices (3), narrow        system databases (5), partner narrow system databases (6),        external databases (7), the World Wide Web (8), external        services (9), xml compliant applications, the Complete Context™        Input Service (601) and combinations thereof.    -   2. The resource context layer identifies and describes the        resources that impact subject function and/or mission measure        performance by time period. The resource description includes        the identification of any sub-resources. The sources of data can        include narrow system databases (5), partner narrow system        databases (6), external databases (7), the World Wide Web (8),        external services (9), xml compliant applications, the Complete        Context™ Input Service (601) and combinations thereof.    -   3. The environment context layer identifies and describes the        factors in the social, natural and/or physical environment that        impact subject function and/or mission measure performance by        time period. The relevant factors are determined via analysis.        The factor description includes the identification of any        sub-factors. The sources of data can include devices (3), narrow        system databases (5), partner narrow system databases (6),        external databases (7), the World Wide Web (8) and external        services (9), xml compliant applications, the Complete Context™        Input Service (601) and combinations thereof.    -   4. The transaction context layers identifies and describes the        events, actions, action priorities, commitments and requirements        of the subject and each entity in the element context layer by        time period. The description identifies the elements and/or        resources that are associated with the event, action, action        priority, commitment and/or requirement. The sources of data can        include narrow system databases (5), partner narrow system        databases (6), external databases (7), the World Wide Web (8),        external services (9), xml compliant applications, the Complete        Context™ Input Service (601) and combinations thereof.    -   5. The relationship context layer defines the relationships        between the first three layers (elements, resources and/or        factors) and the fourth layer (events and/or actions) by time        period. These impacts can be identified by user input (i.e.        process maps and procedures), analysis, narrow system databases        (5), partner narrow system databases (6), external databases        (7), the World Wide Web (8), external services (9), xml        compliant applications, the Complete Context™ Input Service        (601) and combinations thereof.    -   6. The measure context layer(s) identifies and quantifies the        impact of actions, events, elements, factors, resources and        processes (combination of elements) on each entity function        measure by time period. The impact of risks and surprises can be        kept separate or integrated with other element/factor measures.        The impacts are generally determined via analysis. However, the        analysis can be supplemented by input from simulation programs,        the user (40), a subject matter expert (42) and/or a        collaborator (43), narrow system databases (5), partner narrow        system databases (6), external databases (7), the World Wide Web        (8), external services (9), xml compliant applications, the        Complete Context™ Input Service (601) and combinations thereof.    -   7. Reference context layer (optional)—the relationship of the        first six layers to a specified real or virtual coordinate        system. These relationships can be identified by user input        (i.e. maps), input from a subject matter expert (42) and/or a        collaborator (43), narrow system databases (5), partner narrow        system databases (6), external databases (7), the World Wide Web        (8), external services (9), xml compliant applications, the        Complete Context™ Input Service (601), analysis and combinations        thereof; and    -   8. Lexical context layer—defines the terminology used to define        and describe the components of context in the other seven        layers. These lexicon can be identified by user input, input        from a subject matter expert (42) and/or a collaborator (43),        narrow system databases (5), partner narrow system databases        (6), external databases (7), the World Wide Web (8), external        services (9), xml compliant applications, the Complete Context™        Input Service (601), analysis and combinations thereof.        The eight context layers define a complete context for entity        performance for a specified function by time period. We can use        the more precise definition of context to define what it means        to be knowledgeable. Our revised definition would state that an        individual that is knowledgeable about a subject has information        from all eight context layers for the one or more functions he,        she or it is considering. This is important because, once the        complete context is known and modeled any disease can be managed        and/or cured. The knowledgeable individual would be able to use        the information from the eight context layers to:    -   1. identify the range of contexts where models of subject        function performance are applicable; and    -   2. accurately predict subject actions in response to events        and/or actions in contexts where the context is applicable.        The accuracy of the prediction created using the eight types of        context layers reflects the level of knowledge. For simplicity        we will use the R squared (R²) statistic as the measure of        knowledge level. R² is the fraction of the total squared error        that is explained by the model—other statistics can be used to        provide indications of the entity model accuracy including        entropy measures and root mean squared error. The gap between        the fraction of performance explained by the model and 100% is        uncertainty, errors in the model and errors in the data. Table        10 illustrates the use of the information from six of the eight        layers in analyzing a sample personalized medicine context.

TABLE 10 1. Mission: patient health & longevity, financial break evenmeasures 2. Environment: malpractice insurance is increasingly costly 3.Measure: survival rate is 99% for procedure A and 98% for procedure B;treatment in first week improves 5 year survival 18%, 5 year recurrencerate is 7% higher for procedure A 4. Relationship: Dr. X has acommitment to assist on another procedure Monday 5. Resource: operatingroom A time available for both procedures 6. Transaction: patient shouldbe treated next week, his insurance will cover operation 7. Element:operating room, operating room equipment, Dr. XIn addition to defining context, context layers are useful in developingmanagement tools. One use of the layers is establishing budgets and/oralert levels for data within a layer or combinations of layers. Usingthe sample situation illustrated in Table 10, an alert could beestablished for survival rates that drop below 99% in the measure layer.Control can be defined and applied at the transaction and measure levelsby assigning priorities to actions and measures. Using this approach thesystem of the present invention has the ability to analyze and optimizeperformance using user specified priorities, historical measures or somecombination of the two.

Some analytical applications are limited to optimizing the instant(short-term) impact given the elements, resources and the transactionstatus. Because these systems generally ignore uncertainty and theimpact, reference, environment and long term measure portions of acomplete context, the recommendations they make are often at odds withcommon sense decisions made by line managers that have a more completecontext for evaluating the same data. This deficiency is one reason somehave noted that “there is no intelligence in business intelligenceapplications”. One reason some existing systems take this approach isthat the information that defines three important parts of completecontext (relationship, environment and long term measure impact) are notreadily available and must generally be derived. A related shortcomingof some of these systems is that they fail to identify the context orcontexts where the results of their analyses are valid.

In one embodiment, the Personalized Medicine System (100) provides thefunctionality for integrating data from all narrow systems (4), creatinga contextbase (50), developing a Personalized Medicine System (100) andsupporting the Complete Context™ Suite (625) as shown in FIG. 13. Overtime, the narrow systems (4) can be eliminated and all data can beentered directly into the Personalized Medicine System (100) asdiscussed previously. In an alternate mode, the Personalized MedicineSystem (100) would work in tandem with a Process Integration System (99)such as an application server, laboratory information management system,middleware application, extended operating system, data exchange or gridto integrate data, create the contextbase (50), develop a PersonalizedMedicine System (100) and support the Complete Context™ Suite (625) asshown in FIG. 14. In either mode, the system of the present inventionsupports the development and storage of all eight types of contextlayers in order to create a contextbase (50).

The contextbase (50) also enables the development of new types ofanalytical reports including a sustainability report and a controllableperformance report. The sustainability report combines the elementlives, factor lives, risks and an entity context to provide an estimateof the time period over which the current subject performance level canbe sustained. There are three paired options for preparing thereport—dynamic or static mode, local or indirect mode, risk adjusted orpre-risk mode. In the static mode, the current element and factor mix is“locked-in” and the sustainability report shows the time period overwhich the current inventory will be depleted. In the dynamic mode thecurrent element and factor inventory is updated using trendedreplenishment rates to provide a dynamic estimate of sustainability. Thelocal perspective reflects the sustainability of the subject inisolation while the indirect perspective reflects the impact of thesubject on another entity. The indirect perspective is derived bymapping the local impacts to some other entity. The risk adjusted (aka“risk”) and pre-risk modes (aka “no risk”) are self explanatory as theysimply reflect the impact of risks on the expected sustainability ofsubject performance. The different possible combinations of these threeoptions define eight modes for report preparation as shown in Table 11.

TABLE 11 Mode Static or Dynamic Local or Indirect Risk or No Risk 1Static Local Risk 2 Static Local No Risk 3 Static Indirect Risk 4 StaticIndirect No Risk 5 Dynamic Local Risk 6 Dynamic Local No Risk 7 DynamicIndirect Risk 8 Dynamic Indirect No RiskThe sustainability report reflects the expected impact of all contextelements and factors on subject performance over time. It can becombined with the Complete Context™ Forecast Service (603), describedbelow, to produce unbiased reserve estimates. Context elements andcontext factors are influenced to varying degrees by the subject. Thecontrollable performance report identifies the relative contribution ofthe different context elements and factors to the current level ofentity performance. It then puts the current level of performance incontext by comparing the current level of performance with theperformance that would be expected if some or all of the elements andfactors were all at the mid-point of their normal range—the choice ofwhich elements and factors to modify could be a function of the controlexercised by the subject. Both of these reports are pre-defined fordisplay using the Complete Context™ Review Service (607) describedbelow.

The Complete Context™ Review Service (607) and the other services in theComplete Context™ Suite (625) use context frames and sub-context framesto support the analysis, forecast, review and/or optimization of entityperformance. Context frames and sub-context frames are created from theinformation provided by the Personalized Medicine System (100) createdby the system of the present invention (100). The ID to frame table(165) identifies the context frame(s) and/or sub-context frame(s) thatwill be used by each user (40), manager (41), subject matter expert(42), and/or collaborator (43). This information is used to determinewhich portion of the Personalized Medicine System (100) will be madeavailable to the devices (3) and narrow systems (4) that support theuser (40), manager (41), subject matter expert (42), and/or collaborator(43) via the Complete Context™ API (application program interface). Asdetailed later, the system of the present invention can also use othermethods to provide the required context information.

Context frames are defined by the entity function and/or missionmeasures and the context layers associated with the entity functionand/or mission measures. The context frame provides the data,information and knowledge that quantify the impact of actions,constraints, elements, events, factors, preferences, processes,projects, risks and resources on entity performance. Sub-context framescontain information relevant to a subset of one or more functionmeasure/layer combinations. For example, a sub-context frame couldinclude the portion of each of the context layers that was related to anentity process. Because a process can be defined by a combination ofelements, events and resources that produce an action, the informationfrom each layer that was associated with the elements, events, resourcesand actions that define the process would be included in the sub-contextframe for that process. This sub-context frame would provide all theinformation needed to understand process performance and the impact ofevents, actions, element change and factor change on processperformance.

The services in the Complete Context™ Suite (625) are “context aware”(with context quotients equal to 200) and have the ability to processdata from the Personalized Medicine System (100) and its contextbase(50). Another novel feature of the services in the Complete Context™Suite (625) is that they can review entity context from prior timeperiods to generate reports that highlight changes over time and displaythe range of contexts under which the results they produce are valid.The range of contexts where results are valid will be hereinafter bereferred to as the valid context space.

The services in the Complete Context™ Suite (625) also support thedevelopment of customized applications or services. They do this by:

-   -   1. providing ready access to the internal logic of the service        while at the same time protecting this logic from change; and    -   2. using the universal context specification (see FIG. 17) to        define standardized Application Program Interfaces (API's) for        all Complete Context™ Services—these API's allow the        specification of the different context layers using text        information, numerical information and/or graphical        representations of subject context in a format similar to that        shown in FIG. 2A, FIG. 2B. and FIG. 2C.

The first features allow users (40), partners and external services toget information tailored to a specific context while preserving theability to upgrade the services at a later date in an automated fashion.The second feature allows others to incorporate the Complete Context™Services into other applications and/or services. It is worth notingthat this awareness of context is also used to support a true naturallanguage interface (714)—one that understands the meaning of theidentified words—to each of the services in the Suite (625). It shouldbe also noted that each of the services in the Suite (625) supports theuse of a reference coordinate system for displaying the results of theirprocessing when one is specified for use by the user (40). The softwarefor each service in the suite (625) resides in an applet or service withthe context frame being provided by the Personalized Medicine System(100). This software could also reside on the computer (110) with useraccess through a browser (800) or through the natural language interface(714) provided by the Personalized Medicine System (100). Other featuresof the services in the Complete Context™ Suite (625) are brieflydescribed below:

-   -   1. Complete Context™ Analysis Service (602)—analyzes the impact        of user (40) specified changes on a subject for a given context        frame or sub-context frame by mapping the proposed change to the        appropriate context layer(s) in accordance with the schema or        ontology and then evaluating the impact of said change on the        function and/or mission measures. Context frame information may        be supplemented by simulations and information from subject        matter experts (42) as appropriate. This service can also be        used to analyze the impact on changes on any “view” of the        entity that has been defined and pre-programmed for review. For        example, accounting profit using three different standards or        capital adequacy can be analyzed using the same rules defined        for the Complete Context™ Review Service (607) to convert the        context frame analysis to the required reporting format.    -   2. Complete Context™ Auditing Service (624)—is a modified        Complete Context™ Review Service (607) that uses a rules engine        to completely re-process all relevant transactions and compare        the resulting values with the information in a report presented        by management. The Complete Context™ Auditing Service then        combines this information with the information stored in the        Context Base (50) to complete an automated audit of all the        numbers in a report—including reserve estimates—as well as        producing a list of risk factors in order of importance. After        the various calculations are completed, the system of the        present invention produces a discrepancy report where the        reported values in a report is compared to the value computed        using the method and system detailed above.    -   3. Complete Context™ Bridge Service (624)—is a service that        identifies the differences between two context frames and the        best mode for bringing the frames into alignment or congruence.        This service can be very useful in breaking down barriers to        communication and facilitating negotiations.    -   4. Complete Context™ Browser (628)—supports browsing through the        contextbase (50) with a focus on one or more dimensions of the        Universal Context Specification for the user (40) and/or a        subject.    -   5. Complete Context™ Capture and Collaboration Service        (622)—guides one or more subject matter experts (42) and/or        collaborators (43) through a series of steps in order to capture        information, refine existing knowledge and/or develop plans for        the future using existing knowledge. The one or more subject        matter experts (42) and/or collaborators (43) will provide        information and knowledge by selecting from a template of        pre-defined elements, resources, events, factors, actions and        entity hierarchy graphics that are developed from the subject        schema table (157). The one or more subject matter experts (42)        and/or collaborators (43) also have the option of defining new        elements, events, factors, actions and hierarchies. The one or        more subject matter experts (42) and/or collaborators (43) are        first asked to define what type of information and knowledge        will be provided. The choices will include each of the eight        types of context layers as well as element definitions, factor        definitions, event definitions, action definition, impacts,        processes, uncertainty and scenarios. On this same screen, the        one or more subject matter experts (42) and/or collaborators        (43) will also be asked to decide whether basic structures or        probabilistic structures will provided in this session, if this        session will require the use of a time-line and if the session        will include the lower level subject matter. The selection        regarding type of structures will determine what type of samples        will be displayed on the next screen. If the use of a time-line        is indicated, then the user will be prompted to: select a        reference point—examples would include today, event occurrence,        when I started, etc.; define the scale being used to separate        different times—examples would include seconds, minutes, days,        years, light years, etc.; and specify the number of time slices        being specified in this session. The selection regarding which        type of information and knowledge will be provided determines        the display for the last selection made on this screen. There is        a natural hierarchy to the different types of information and        knowledge that can be provided by a one or more subject matter        experts (42) and/or collaborators (43). For example, measure        level knowledge would be expected to include input from the        impact, element, transaction and resource context layers. If the        one or more subject matter experts (42) and/or collaborators        (43) agrees, the service will guide the one or more subject        matter experts (42) and/or collaborators (43) to provide        knowledge for each of the “lower level” knowledge areas by        following the natural hierarchies. Summarizing the preceding        discussion, the one or more subject matter experts (42) and/or        collaborators (43) has used the first screen to select the type        of information and knowledge to be provided (measure layer,        impact layer, transaction layer, resource layer, environment        layer, element layer, reference layer, event risk or scenario).        The one or more subject matter experts (42) and/or collaborators        (43) have also chosen to provide this information in one of four        formats: basic structure without timeline, basic structure with        timeline, relational structure without timeline or relational        structure with timeline. Finally, the one or more subject matter        experts (42) and/or collaborators (43) have indicated whether or        not the session will include an extension to capture “lower        level” knowledge. Each selection made by the one or more subject        matter experts (42) and/or collaborators (43) will be used to        identify the combination of elements, events, actions, factors        and entity hierarchy chosen for display and possible selection.        This information will be displayed in a manner that is somewhat        similar to the manner in which stencils are made available to        Visio® users for use in the workspace. The next screen displayed        by the service will depend on which combination of information,        knowledge, structure and timeline selections that were made by        the one or more subject matter experts (42) and/or collaborators        (43). In addition to displaying the sample graphics to the one        or more subject matter experts (42) and/or collaborators (43),        this screen will also provide the one or more subject matter        experts (42) and/or collaborators (43) with the option to use        graphical operations to change impacts, define new impacts,        define new elements, define new factors and/or define new        events. The thesaurus table (164) in the contextbase (50)        provides graphical operators for: adding an element or factor,        acquiring an element, consuming an element, changing an element,        factor or event risk values, adding a impact, changing the        strength of a impact, identifying an event cycle, identifying a        random impact, identifying commitments, identifying constraints        and indicating preferences. The one or more subject matter        experts (42) and/or collaborators (43) would be expected to        select the structure that most closely resembles the knowledge        that is being communicated or refined and add it to the        workspace being displayed. After adding it to the workspace, the        one or more subject matter experts (42) and/or collaborators        (43) will then edit elements, factors, resources and events and        add elements, factors, resources events and descriptive        information in order to fully describe the information or        knowledge being captured from the context frame represented on        the screen. If relational information is being specified, then        the one or more subject matter experts (42) and/or collaborators        (43) will be given the option of using graphs, numbers or letter        grades to communicate the information regarding probabilities.        If a timeline is being used, then the next screen displayed will        be the screen for the same perspective from the next time period        in the time line. The starting point for the next period        knowledge capture will be the final version of the knowledge        captured in the prior time period. After completing the        knowledge capture for each time period for a given level, the        Service (622) will guide the one or more subject matter experts        (42) and/or collaborators (43) to the “lower level” areas where        the process will be repeated using samples that are appropriate        to the context layer or area being reviewed. At all steps in the        process, the information in the contextbase (50) and the        knowledge collected during the session will be used to predict        elements, resources, actions, events and impacts that are likely        to be added or modified in the workspace. These “predictions”        are displayed using flashing symbols in the workspace. The one        or more subject matter experts (42) and/or collaborators (43)        are given with the option of turning the predictive prompting        feature off. After the information and knowledge has been        captured, the graphical results are converted to data base        entries and stored in the appropriate tables (141, 142, 143,        144, 145, 149, 154, 156, 157, 158, 162 or 168) in the        contextbase (50). Data from simulation programs can also be        added to the contextbase (50) to provide similar information or        knowledge. This Service (622) can also be used to verify the        veracity of some new assertion by mapping the new assertion to        the subject model and quantifying any reduction in explanatory        power and/or increase in uncertainty of the entity performance        model.    -   6. Complete Context™ Customization Service (621)—service for        analyzing and optimizing the impact of data, information,        products, projects and/or services by customizing the features        included in or expressed by an offering for a subject for a        given context frame or sub-context frame. The context frame or        sub-context frame may be provided by the Complete Context™        Summary Service (617). Some of the products and services that        can be customized with this service include medicine, medical        treatments, medical tests, software, technical support,        equipment, computer hardware, devices, services,        telecommunication equipment, living space, buildings,        advertising, data, information and knowledge. Other        customizations may rely on the Complete Context™ Optimization        Service (604) working alone or in combination with the Complete        Context™ Search Service (609). Context frame information may be        supplemented by simulations and information from subject matter        experts (42) as appropriate.    -   7. Complete Context™ Display Service (614)—manages the        availability and display of data, information, and knowledge        related to one or more context frames and/or sub context frames        to a user (40), manager (41), subject matter expert (42), and/or        collaborator (43) on a continuous basis using a portal (11),        service (9), device (3), computer (110) and/or other display. To        support this effort the Complete Context™ Display Service (614)        supports RSS feeds, manages one or more caches (119) that        support projections and display(s) utilizing the caches and/or        data feeds. The priority assigned to the data and information        made available is determined via a randomized algorithm that        blends frequency of use, recency of use, cost to retrieve and        time to retrieve measures with a relevance measure for each of        the one or more context frames and/or sub context frames being        supported (see Complete Context™ Scout Service (616) for a        discussion of relevance measure computation). As the user (40),        manager (41), subject matter expert (42), and/or collaborator        (43) context changes (for example when location changes or the        World Trade Center collapses), the relevance measure will change        which will in turn drive this Service (614) to change the mix in        the cache, RSS feed or projection in order to ensure that data        and/or information that is most relevant to the new context is        readily available. This Service (614) can be combined with the        Complete Context™ Optimization Service (604) to ensure that        messages, emails, network traffic, computer resources and        related devices are providing the optimal support for a given        context. In a similar fashion it can be combined with the        Complete Context™ Capture and Collaboration Service (622) to        ensure that the one or more subject matter experts (42) and/or        collaborators (43) have the data, information and knowledge they        need to complete their input to the system of the present        invention. The service can be used to purge data, information        and knowledge that is no longer relevant to the given context.        In an interactive commerce setting this application can be used        to: identify the content that is most relevant to a customer's        context and/or display an ad or technical support information        relevant to said context. In this same setting it can be        combined with other services in the suite (625) complete a sale        using the Complete Context™ Exchange Service (608), purchase        content that has a value in excess of its cost in the current        context using the Complete Context™ Exchange Service (608),        customize and buy an offering using the Complete Context™        Customization Service (621) in conjunction with the Complete        Context™ Exchange Service (608), and/or customize and sell an        offering using the Complete Context™ Customization Service (621)        in conjunction with the Complete Context™ Exchange Service        (608).    -   8. Complete Context™ Exchange Service (608)—identifies desirable        exchanges of resources, elements, commitments, data and        information with other entities in an automated fashion. This        service calls on Complete Context™ Analysis Service (602) in        order to review proposed prices. In a similar manner the service        calls on the Complete Context™ Optimization Service (604) to        determine the optimal parameters for an exchange before        completing a transaction. For partners or customers that provide        access to their data that is sufficient to define a shared        context, the exchange service can use the other services from        the Complete Context™ Suite (625) to analyze and optimize the        exchange for the combined parties. The actual transactions are        completed by the Complete Context™ Input Service (601).    -   9. Complete Context™ Forecast Service (603)—forecasts the value        of specified variable(s) using data from all relevant context        layers. Completes a tournament of forecasts for specified        variables and defaults to a multivalent combination of forecasts        from the tournament using methods similar to those first        described in cross referenced U.S. Pat. No. 5,615,109. In        addition to providing the forecast, this service will provide        the confidence interval associated with the forecast and provide        the user (40) with the ability to identify the data that needs        to be collected in order improve the confidence associated with        a given forecast which will make the process of refining        forecasts more efficient.    -   10. Complete Context™ Indexing Service (619)—service for        developing composite and covering indices for data, information        and knowledge in contextbase (50) using the impact cutoff and        node depth specified by the user (40) in the system settings        table (162) for contexts and combination of contexts.    -   11. Complete Context™ Input Service (601)—service for recording        actions and commitments into the contextbase (50). The interface        for this service is a template accessed via a browser (800) or        the natural language interface (714) provided by the Medicine        System (100) that identifies the available element, transaction,        resource and measure data for inclusion in a transaction. After        the user has recorded a transaction the service saves the        information regarding each action or commitment to the        contextbase (50). Other services such as Complete Context™        Analysis (602), Planning (605) or Optimization (604) Services        can interface with this service to generate actions, commitments        and/or transactions in an automated fashion. Complete Context™        Bots (650) can also be programmed to provide this functionality.    -   12. Complete Context™ Journal Service (630) (aka the “daily        me”)—uses natural language generation to automatically develop        and deliver a prioritized summary of news and information in any        combination of formats covering a specified time period (hourly,        daily, weekly, etc.) that is relevant to a given subject context        or context frame. Relevance is determined in a manner identical        to that described previously for the Complete Context™ Scout        Service (616) save for the fact that the user (40) is free to        modify the node depth, subject entity definition and/or impact        cutoff used for evaluating relevance using a wizard.    -   13. Complete Context™ Metrics and Rules Service (611)—tracks and        displays the causal performance indicators for context elements,        resources and factors for a given context frame as well as the        rules used for segmenting context components into smaller groups        for more detailed analysis. Rules and patterns can be discovered        using an algorithm tournament that includes the Apriori        algorithm, the sliding window algorithm; differential        association rule mining, beam-search, frequent pattern growth        and decision trees.    -   14. Complete Context™ Optimization Service (604)—simulates        entity performance and identifies the optimal mix of actions,        events and/or context components for operating a specific        context frame or sub context frame given the constraints,        uncertainty and the defined function and/or mission measures. A        tournament is used to select the best algorithm from the group        consisting of genetic algorithms, the calculus of variations,        constraint programming, game theory, mixed integer linear        programming, multi-criteria maximization, linear programming,        semi-definite programming, smoothing and highly optimized        tolerance. Because most entities have more than one function        (and more than one measure), the genetic algorithm and        multi-criteria maximizations are used most frequently. This        service can also be used to optimize Complete Context™ Review        Service (607) measures using the same rules defined for the        Complete Context™ Review Service (607) to define context frames        in the required format before optimization.    -   15. Complete Context™ Planning Service (605)—service that is        used to: establish measure priorities, establish action        priorities, and establish expected performance levels (aka        budgets) for actions, events, elements resources and measures.        These priorities and performance level expectations are saved in        the corresponding layer in the contextbase (50). For example,        measure priorities are saved in the measure layer table (145).        This service also supports collaborative planning when context        frames that include one or more partners are created (see FIG.        2B).    -   16. Complete Context™ Profiling Service (615)—service for        developing the best estimate of complete entity context from        available subject related data and information. If a complete        context has been developed for a similar entity, then the        Complete Context™ Profiling Service (615) will identify: the        portion of behavior that is generally explained by the level of        detail in the profile, differences from the similar entity,        expected ranges of behavior and sources of data that are        generally used to produce a more complete context before        completing an analysis of the available data. The contexts        developed by this service (615) can be used to.    -   17. Complete Context™ Project Service (606)—service for        analyzing and optimizing the impact of a project or a group of        projects on a context frame. Project is broadly defined to        include any development or diminution of any components of        context and/or entities. Context frame information may be        supplemented by simulations and information from subject matter        experts (42) as appropriate.    -   18. Complete Context™ Review Service (607)—service for reviewing        components of context and measures alone or in combination.        These reviews can be completed with or without the use of a        reference layer. This service uses a rules engine to transform        contextbase (50) historical information into standardized        reports that have been defined by different entities. Other        standardized, non-financial performance reports have been        developed for medical entities, military operations and        educational institutions. The sustainability and controllable        performance reports described previously are also pre-defined        for calculation and display. The rules engine produces each of        these reports on demand for review and optional publication.    -   19. Complete Context™ Scout Service (616)—service that works        with the Complete Context™ Indexing Service (619) to proactively        identify data, information and/or knowledge regarding choices        the subject will be making in the near future using the time        frame or time frames defined by user (40) in system settings        table (162). The Complete Context™ Scout (616) uses process        maps, preferences and the Complete Context™ Forecast Service        (603) to identify the choices that it expects the subject to        make in the near future. It then uses weight of        evidence/satisfaction algorithms including banburismus to        determine which choices need additional data, information and/or        knowledge to support an informed decision within parameters        selected by the user (40) in the system settings table (162). It        of course, also determines which choices are already supported        by sufficient data, information and/or knowledge. The relative        priority given to the data, information and/or knowledge        selected by the Complete Context™ Scout (616) is a blended        function of the relevance rankings produced by several measures        of relevance including ontology alignment measures, semantic        alignment measures, cover density rankings, vector space model        measurements, okapi similarity measurements, node rankings (as        described in U.S. Pat. No. 6,285,999, which is incorporated        herein by reference) which can be obtained from Google, three        level relevance scores and hypertext induced topic selection        algorithm scores. The relevance measure detailed in cross        referenced application Ser. No. 10/237,021 can also be used to        identify relevance. The Complete Context™ Scout Service (616)        evaluates relevance by utilizing the relationships and impacts        that define a complete entity context to the node depth and        impact cutoff specified by the user in the system settings table        (162) as the basis for scoring using the techniques outlined        above. The node depth identifies the number of node connections        that are used to identify components of context to be considered        in determining the relevance score. For example, if a single        entity (as shown in FIG. 2A) was expected to need information        about a resource (906) and a node depth of one had been        selected, then the relevance rankings would consider the        components of context that are linked to resources by a single        link. Using this approach data, information and/or knowledge        that contains and/or is closely linked to a similar mix of        context components will receive a higher ranking. As shown in        FIG. 2A, this would include locations (901), projects (902),        events (903), virtual locations (904), elements (907), actions        (908), transactions (909) and processes (911) that had an impact        greater than or equal to the impact cutoff. The Complete        Context™ Scout Service (616) has the ability to use word sense        disambiguation algorithms to clarify the terms being selected        for search, normalizes the terms selected for search using the        Porter Stemming algorithm or an equivalent and uses        collaborative filtering to learn the combination of ranking        methods that are generally preferred for identifying relevant        data, information and/or knowledge given the choices being faced        by the subject for each context and/or context frame.    -   20. Complete Context™ Search Service (609)—service for locating        the most relevant data, information, services and/or knowledge        for a given context frame or sub context frame in one of two        modes—direct or indirect. In the direct mode, the relevant data,        information and/or services are identified and presented to the        user (40). In the indirect mode, candidate data, information        and/or services are identified using publicly available search        engine results that are re-analyzed before presentation to the        user (40). This service can be combined with the Complete        Context™ Customization Service (621) to identify and provide        customized ads and/or other information related to a given        context frame as relevance increases (through movement relative        to a reference frame, external changes, etc.). Relevance is        determined in a manner identical to that described previously        for the Complete Context™ Scout (616) save for the fact that the        user (40) is free to modify the node depth, subject definition        and/or impact cutoff used for evaluating relevance using a        wizard. Any indices associated with the revised subject        definitions would automatically be changed by the Complete        Context™ Index Service (619) as required to support the changed        definition. The user (40) could choose to change the subject        definition for any number of reasons. For example, he or she may        wish to focus on only one entity context for a vertical search.        Another reason for changing the definition would be to        incorporate one or more contexts from other entities in a new        definition. For example, an employee could choose to search for        information relevant to a combination of one or more of his or        her contexts (for example, his or her employee context) and one        or more contexts of the employer/company (for example, the        context of his project or division). As part of its processing,        the Complete Context™ Search Engine (609) identifies the        relationship between the requested information and other        information by using the relationships and measure impacts        identified in the contextbase (50). It uses this information to        display the related data and/or information in a graphical        format similar to the formats used in FIG. 2A, FIG. 2B and/or        FIG. 2C. Again, the node depth cutoff is used to determine how        “deep” into the graph the search is performed. The user (40) has        the option of focusing on any block in a graphical summary of        relevant information using the Complete Context™ Browser (628),        for example the user (40) could choose to retrieve information        about the resources (906) that support an entity (900). As        discussed previously (see definitions), the subject may not be        the user (40). If this is the case, then the user's context is        considered as part of normal processing. Information obtained        from the natural language interface (714) could be part of this        context;    -   21. Complete Context™ Summary Service (617)—develops a summary        of entity context using the Universal Context Specification (see        FIG. 17) in an rdf format that contains the portion of the        specification approved for release by the user (40) for use by        other applications, services and/or entities. For example, the        user (40) could send a summary of two contexts (family member        and church-member) to a financial planner for use in        establishing a portfolio that will help the user (40) realize        his or her goals with respect to these two contexts. This        Complete Context™ Summary can be used by others providing goods,        services and information (such as other search engines) to        tailor their offerings to the portion of context that has been        revealed.    -   22. Complete Context™ Underwriting Service (620)—analyzes a        context frame or sub-context frame for an entity in order to:        evaluate entity liquidity, evaluate entity creditworthiness,        evaluate entity risks and/or complete valuations. It can then        use this information to support the: transfer of liquidity to or        from said entity, transfer of risks to or from said entity,        securitization one or more entity risks, underwriting of entity        related securities, packaging of entity related securities into        funds or portfolios with similar characteristics (i.e.        sustainability, risk, uncertainty equivalent, value, etc.)        and/or package entity related securities into funds or        portfolios with dissimilar characteristics (i.e. sustainability,        risk, uncertainty equivalent, value, etc.). As part of        securitizing entity risks the Complete Context™ Underwriting        Service (620) identifies an uncertainty equivalent for the risks        being underwritten. This innovative analysis combines quantified        uncertainty by type with the securitized risks to give investors        a more complete picture of the risk they are assuming when they        buy a risk security. All of these analyses can rely on the        measure layer information stored in the contextbase (50), the        sustainability reports, the controllable performance reports and        any pre-defined review format. Context frame information may be        supplemented by simulations and information from subject matter        experts as appropriate.        The services within the Complete Context™ Suite (625) can be        combined in any combination and/or joined together in any        combination in order to complete a specific task. For example,        the Complete Context™ Review Service (607), the Complete        Context™ Forecast Service (603) and the Complete Context™        Planning Service (605) can be joined together to process a        series of calculations. The Complete Context™ Analysis Service        (602) and the Complete Context™ Optimization Service (604) are        also joined together frequently to support performance        improvement activities. In a similar fashion the Complete        Context™ Optimization Service (604) and the Complete Context™        Capture and Collaboration Service (622) are often combined to        support knowledge transfer and simulation based training. The        services in the Complete Context™ Suite (625) will hereinafter        be referred to as the standard services or the services in the        Suite (625).

The Personalized Medicine System (100) utilizes a novel software andsystem architecture for developing the complete entity context used tosupport entity related systems and services. Narrow systems (4)generally try to develop and use a picture of how part of an entity isperforming (i.e. supply chain, heart functionality, etc.). The user (40)is then left with an enormous effort to integrate these differentpictures—often developed from different perspectives—to form a completepicture of entity performance. By way of contrast, the PersonalizedMedicine System (100) develops complete pictures of entity performancefor every function using a common format (i.e. see FIG. 2A, FIG. 2B andFIG. 2C) before combining these pictures to define the complete entitycontext and a contextbase (50) for the subject. The detailed informationfrom the complete entity context is then divided and recombined in acontext frame or sub-context frame that is used by the standard servicesin any variety of combinations for analysis and performance management.

The contextbase (50) and entity contexts are continually updated by thesoftware in the Personalized Medicine System (100). As a result, changesare automatically discovered and incorporated into the processing andanalysis completed by the Personalized Medicine System (100). Developingthe complete picture first, instead of trying to put it together fromdozens of different pieces can allow the system of the present inventionto reduce IT infrastructure complexity by orders of magnitude whiledramatically increasing the ability to analyze and manage subjectperformance. The ability to use the same software services to analyze,manage, review and optimize performance of entities at different levelswithin a domain hierarchy and entities from a wide variety of differentdomains further magnifies the benefits associated with thesimplification enabled by the novel software and system architecture ofthe present invention.

The Personalized Medicine System (100) provides several other importantfeatures, including:

-   -   1. the system learns from the data which means that it supports        the management of new aspects of entity performance as they        become important without having to develop a new system;    -   2. the user is free to specify any combination of functions and        measures for analysis; and    -   3. support for the automated development and use of bots and        other independent software applications (such as services) that        can be used to, among other things, initiate actions, complete        actions, respond to events, seek information from other entities        and provide information to other entities in an automated        fashion.

To illustrate the use of the Personalized Medicine System (100), adescription of the use of the services in the Complete Context™ Suite(625) to support a small clinic (an organization entity) in treating apatient (an organism entity that becomes an element of the clinicentity) will be provided. The clinic has the same measures described intable 10 for a medical facility. An overview of the one embodiment of asystem to support this clinic is provided in FIG. 16. The patient comesto the clinic complaining of blood in the urine. After arriving at theclinic, he fills out a form that details his medical history. After theform is filled out, the patient has his weight and blood pressurechecked by an aide before seeing a doctor. The doctor reviews thepatient's information, examines the patient and prescribes a treatmentbefore moving on to see the next patient. In the narrative that follows,the support provided by the Personalized Medicine System (100) for eachstep in the patient visit and the subsequent follow up will bedescribed. The narrative assumes that the system was installed some timeago and has completed the processing used to develop a complete ontologyand contextbase (50) for the clinic along with the associated processmaps.

Process maps define the expected sequence and timing of events,commitments and actions as treatment progresses. If the timing orsequence of events fail to follow the expected path, then the alertsbuilt into the tactical layer will notify designated staff (element).Process maps also identify the agents, assets and resources that will beused to support the treatment process. FIG. 15 shows a sample processmap. Process maps can be established centrally in accordance withguidelines or they can be established by individual clinicians inaccordance with organization policy. In all cases they are stored in therelationship layer. Before selecting a process map, the doctor couldactivate the Complete Context™ Analysis Service (602) to review theexpected instant impacts and outcomes from different combinations ofprocedures and treatments that are available under the currentformulary. This information could be used to support the development ofa new process map (if organization policy permits this). In any event,after the doctor selects a process map for the treatment of thespecified diagnosis, the associated process commitments and alerts areassociated with the patient and stored in the tactical layer. Therequired paperwork is automatically generated by the process map andsigned as required by the doctor.

If the clinic is small, the history information from the clinic can besupplemented with data provided by external sources (such as the AMA,NIH, insurance companies, HMOs, drug companies, etc.) to provide datafor a sufficient population to complete the processing to establishexpected ranges for the expected mix of patients and diseases.

Data entry can be completed in a number of ways for each step in thevisit. The most direct route would be to use the Complete Context™ InputService (601) or any xml compliant application (such as newer MicrosoftOffice and Adobe applications) with a device such as a pc or personaldigital assistant to capture information obtained during the visit usingthe natural language interface (714) or a pre-defined form. Once thedata are captured it is integrated with the contextbase (50) in anautomated fashion. A paper form could be used for facilities that do nothave the ability to provide pc or pda access to patients. This paperform can be transcribed or scanned and converted into an xml documentwhere it could be integrated with the contextbase (50) in an automatedfashion. If the patient has used a Personalized Medicine System (100)that stored data related to his or her health, then this informationcould be communicated to the Medicine System (100) in an automatedfashion via wireless connectivity, wired connectivity or the transfer offiles from the patient's Medicine System (100) to a recordable media.Recognizing that there are a number of options for completing data entrywe will simply say that “data entry is completed” when describing eachstep.

Step 1—the patient details prior medical history and data entry iscompleted. Because the patient is new, a new element for the patientwill automatically be created within the ontology and contextbase (50)for the clinic. The medical history will be associated with the newelement for the patient in the element layer. Any information regardinginsurance will be tagged and stored in the tactical layer which woulddetermine eligibility by communicating with the appropriate insuranceprovider. The measure layer will in turn use this information todetermine the expected margin and/or generate a flag if the patient isnot eligible for insurance.

Step 2—weight and blood pressure are checked by an aide and data entryis completed. The medical history data are used to generate a list ofpossible diagnoses based on the proximity of the patient's history topreviously defined disease clusters and pathways by the analytics thatsupport the instant impact and outcome layers. Any data that is out ofthe normal range for the cluster will be flagged for confirmation by thedoctor. The Personalized Medicine System (100) would also query externaldata providers to see if the out of range data correlates with any newclusters that may have been identified since the clinic's contextbase(50) and ontology were established. The analytics in the relationshiplayer would then identify the tests that should be conducted to validateor invalidate possible diagnoses. Preference would be given to the teststhat provide information that is relevant to the highest number ofpotential diagnoses for the lowest cost. If the patient's historydocumented the diagnostic imaging history, then consideration would alsobe given to cumulative radiation levels when recommending tests.

Step 3—the doctor refers the patient to a diagnostic imaging centerusing the process map for a pet scan (to look for tumors on thepatient's kidneys). He also refers the patient for genetic testing witha new process map that assesses the patient's likely response to a newtype of chemotherapy.

Step 4—The images and genetic tests are completed in accordance with thespecified process maps. As part of this process, the PersonalizedMedicine Service (101) in the imaging center highlights any probabletumors before displaying the image to the radiologist for diagnosis. ThePersonalized Medicine Service (102) in the genetic testing center woulddetermine if the test array displayed the biomarkers (indicators) thatindicated a likely favorable response to the new chemotherapy beforehaving the results analyzed by a technician. In both cases the resultsof the analyses are sent to the Personalized Medicine System (100) inthe clinic for automated integration with the patient's medical history.At this point, the Personalized Medicine System (100) in the clinicwould automatically update the list of likely diagnoses to reflect thenewly gathered information.

Step 5—the doctor reviews the information for the patient from thecontextbase (50) using the Complete Context™ Review Service (607) on adevice (3) such as a pda or personal computer. The doctor will have theability to define the exact format of the display by choosing the mix ofgraphical and text information that will be displayed. At this point,the doctor determines that the patient probably has kidney cancer andrefers the patient to a surgeon for further treatment. He activates theprocess map for a surgical referral, among other things this process mapsends the patients medical history to the surgeon's context servicesystem (103) in an automated fashion.

Step 6—the surgeon examines the medical records and the patient beforescheduling surgery for a hospital where he has privileges. He thenactivates the kidney surgery process map which forwards the medicalrecords to the hospital context service system (104).

Step 7—the surgeon completes a biopsy that confirms the presence of amalignant tumor before scheduling and completing the required surgery.After the surgery is completed, the surgeon then activates thepre-defined process map for the new chemotherapy (as noted previously,the patient's genetic biomarkers indicated that he would likely respondwell to this new treatment). As information is added to the patient'smedical history in the hospital context service (104), it is alsocommunicated back to the Personalized Medicine System (100) in theclinic for inclusion in the patient's medical history in an automatedfashion and to the relevant insurance company.

Step 8—follow up. The chemotherapy process map the doctor selected isused to identify the expected sequence of events that the patient willuse to complete his treatment. If the patient fails to complete an eventwithin the specified time range or in the specified order, then thealerts built into the tactical layer will generate email messages to thedoctor and/or case worker assigned to monitor the patient for follow-upand possible corrective action. Bots could be used to automate someaspects of routine follow-up like sending reminders or requests forstatus via email or regular mail. This functionality could also be usedto collect information about long-term outcomes from patients in anautomated fashion.

The process map follow-up processing continues automatically until theprocess ends, a clinician changes the process map for the patient or thepatient visits the facility again and the process described above isrepeated.

In short, the services in the Complete Context™ Suite (625) worktogether with the Personalized Medicine System (100) to provideknowledgeable support to anyone trying to analyze, manage and/oroptimize actions, processes and outcomes for any subject. Thecontextbase (50) supports the services in the Complete Context™ Suite(625) as described above. The contextbase (50) provides six importantbenefits:

-   -   1. By directly supporting entity performance, the system of the        present invention guarantees that the contextbase (50) will        provide a tangible benefit to the entity.    -   2. The measure focus allows the system to partition the search        space into two areas with different levels of processing. Data        and information that is known to be relevant to the defined        functions and/or measures as well as data that are not thought        to be relevant. The system does not ignore data that is not        known to be relevant; however, it is processed less intensely.        This information can also be used to identify data for archiving        or disposal.    -   3. The processing completed in contextbase (50) development        defines and maintains the relevant schema or ontology for the        entity. This schema or ontology can be flexibly matched with        other ontologies in order to interact with other entities that        have organized their information using a different ontology.        This functionality also enables the automated extraction and        integration of data from the semantic web.    -   4. Defining the complete subject context allows every piece of        data that is generated to be placed “in context” when it is        first created. Traditional systems generally treat every piece        of data in an undifferentiated fashion. As a result, separate        efforts are often required to find the data, define a context        and then place the data in context.    -   5. The contextbase (50) includes robust models of the components        of context that drive action and event frequency as well as        levels to vary. This capability is very useful in developing        action plans to improve measure performance.    -   6. The focus on primary subject functions also ensures the        longevity of the contextbase (50) as entity primary functions        rarely change. For example, the primary function of each cell in        the human body has changed very little over the last 10,000        years.        Some of the important features of the patient centric approach        are summarized in Table 13.

TABLE 13 Characteristic Personalized Medicine System (100) Tangiblebenefit Built-in Computation/ Partitioned Search Space Ontologydevelopment Automated and maintenance Ability to analyze new Automatic -learns from data element, resource or factor Measures in alignmentAutomatic Data in context Automatic Service longevity Equal to longevityof definable measure(s)

To facilitate its use as a tool for improving performance, thePersonalized Medicine System (100) produces reports in formats that aregraphical and highly intuitive. By combining this capability with thepreviously described capabilities (developing context, flexibly definingrobust performance measures, optimizing performance, reducing ITcomplexity and facilitating collaboration) the Personalized MedicineSystem (100) gives individuals, groups and clinicians the tools theyneed to model, manage and improve the performance of any subject.

BRIEF DESCRIPTION OF DRAWINGS

These and other objects, features and advantages of the presentinvention will be more readily apparent from the following descriptionof one embodiment of the invention in which:

FIG. 1 is a block diagram showing the major processing steps of thepresent invention;

FIG. 2A, FIG. 2B and FIG. 2C are block diagrams showing a relationshipbetween constraints, elements, events, factors, locations, measures,missions, processes and subject actions/behavior;

FIG. 3 shows a relationship between an entity and other entities,processes and groups;

FIG. 4 is a diagram showing the tables in the contextbase (50) of thepresent invention that are utilized for data storage and retrievalduring the processing;

FIG. 5 is a block diagram of an implementation of the present invention;

FIG. 6A, FIG. 6B and FIG. 6C are block diagrams showing the sequence ofsteps in the present invention used for specifying system settings,preparing data for processing and specifying the subject measures;

FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D, FIG. 7E, FIG. 7F, FIG. 7G and FIG.7H are block diagrams showing the sequence of steps in the presentinvention used for creating a contextbase (50) for a subject;

FIG. 8A and FIG. 8B are block diagrams showing the sequence in steps inthe present invention used in propagating a Personalized MedicineService, creating bots, services and performance reports;

FIG. 9 is a diagram showing the data windows that are used for receivinginformation from and transmitting information via the interface (700);

FIG. 10 is a block diagram showing the sequence of processing steps inthe present invention used for identifying, receiving and transmittingdata with narrow systems (4);

FIG. 11 is a diagram showing how the Personalized Medicine System (100)develops and supports a natural language interface (714);

FIG. 12 is a sample report showing the efficient frontier for Entity XYZand the current position of XYZ relative to the efficient frontier;

FIG. 13 is a diagram showing one embodiment of a Personalized MedicineSystem (100) for a clinic;

FIG. 14 is a diagram showing how the Personalized Medicine System (100)for a clinic can be used in conjunction with an integration platform orexchange (99);

FIG. 15 is a diagram showing a portion of a process map for treating amental health patient;

FIG. 16 is a diagram showing an embodiment of the Personalized MedicineService (100) for a clinic that is connected with a PersonalizedMedicine Service (107) for a patient, a Personalized Medicine Service(106) for a health plan and an exchange (99); and

FIG. 17 shows a universal context specification format.

DETAILED DESCRIPTION OF ONE PREFERRED EMBODIMENT

FIG. 1 provides an overview of the processing completed by theinnovative system for developing a Personalized Medicine System (100).In accordance with the present invention, an automated system and methodfor developing a contextbase (50) that supports the development of aPersonalized Medicine System (100) is provided. In one preferredembodiment the contextbase (50) contains context layers for each subjectmeasure. Processing starts in this Medicine System (100) when the datapreparation portion of the application software (200) extracts data froma narrow system database (5); an external database (7); a world wide web(8), external services (9) and optionally, a partner narrow systemdatabase (6) via a network (45). The connection to the network (45) canbe via a wired connection, a wireless connection or a combinationthereof. It is to be understood that the World Wide Web (8) alsoincludes the semantic web that is being developed. Data may also beobtained from a Complete Context™ Input Service (601) or otherapplications that can provide xml output. For example, newer versions ofMicrosoft® Office and Adobe® Acrobat® can be used to provide data inputto the Medicine System (100) of the present invention.

After data are prepared, entity functions are defined and subjectmeasures are identified, as part of contextbase (50) development in thesecond part of the application software (300). The contextbase (50) isthen used to create a Personalized Medicine System (100) in the thirdstage of processing. The processing completed by the PersonalizedMedicine System (100) may be influenced by a user (40) or a manager (41)through interaction with a user-interface portion of the applicationsoftware (700) that mediates the display, transmission and receipt ofall information to and from the Complete Context™ Input Service (601) orbrowser software (800) such as the Mozilla or Opera browsers in anaccess device (90) such as a phone, personal digital assistant orpersonal computer where data are entered by the user (40). The user (40)and/or manager (41) can also use a natural language interface (714)provided by the Personalized Medicine System (100).

While only one database of each type (5, 6 and 7) is shown in FIG. 1, itis to be understood that the Medicine System (100) can processinformation from all narrow systems (4) listed in Tables 4, 5, 6 and/or7 as well as the devices (3) listed in Table 8 for each entity beingsupported. In one embodiment, all functioning narrow systems (4)associated with each entity will provide data access to the MedicineSystem (100) via the network (45). It should also be understood that itis possible to complete a bulk extraction of data from each database (5,6 and 7), the World Wide Web (8) and external service (9) via thenetwork (45) using peer to peer networking and data extractionapplications. In one embodiment, the data extracted via the network (45)are tagged in a virtual database that leaves all data in the originaldatabases where it can be retrieved and optionally converted for use incalculations by the analysis bots over a network (45). In alternateembodiments, the data could also be stored in a database, datamart, datawarehouse, a cluster (accessed via GPFS), a virtual repository or astorage area network where the analysis bots could operate on theaggregated data.

The operation of the system of the present invention is determined bythe options the user (40) and manager (41) specify and store in thecontextbase (50). As shown in FIG. 4, the contextbase (50) containstables for storing data by context layer including: a key terms table(140), a element layer table (141), a transaction layer table (142), anresource layer table (143), a relationship layer table (144), a measurelayer table (145), a unassigned data table (146), an internet linkagestable (147), a causal link table (148), an environment layer table(149), an uncertainty table (150), a context space table (151), anontology table (152), a report table (153), a reference layer table(154), a hierarchy metadata table (155), an event risk table (156), asubject schema table (157), an event model table (158), a requirementtable (159), a context frame table (160), a context quotient table(161), a system settings table (162), a bot date table (163), aThesaurus table (164), an id to frame table (165), an impact model table(166), a bot assignment table (167), a scenarios table (168), a naturallanguage table (169), a phoneme table (170), a word table (171) and aphrase table (172). The system of the present invention has the abilityto accept and store supplemental or primary data directly from userinput, a data warehouse, a virtual database, a data preparation systemor other electronic files in addition to receiving data from thedatabases described previously. The system of the present invention alsohas the ability to complete the necessary calculations without receivingdata from one or more of the specified databases. However, in theembodiment described herein all information used in processing isobtained from the specified data sources (5, 6, 7, 8, 9 and 601) for thesubject and made available using a virtual database.

As shown in FIG. 5, one embodiment of the present invention is acomputer Medicine System (100) illustratively comprised of a computer(110). The computer (110) is connected via the network (45) to anInternet browser appliance (90) that contains Internet software (800)such as a Mozilla browser or an Opera browser. The browser (800) willsupport RSS feeds.

In one embodiment, the computer (110) has a read/write random accessmemory (111), a hard drive (112) for storage of a contextbase (50) andthe application software (200, 300, 400 and 700), a keyboard (113), acommunication bus (114), a display (115), a mouse (116), a CPU (117), aprinter (118) and a cache (119). As devices (3) become more capable,they be used in place of the computer (110). Larger entities may requirethe use of a grid or cluster in place of the computer (110) to supportComplete Context™ Service processing requirements. In an alternateconfiguration, all or part of the contextbase (50) can be maintainedseparately from a device (3) or computer (110) and accessed via anetwork (45) or grid.

The application software (200, 300, 400 and 700) controls theperformance of the central processing unit (117) as it completes thecalculations used to support Complete Context™ Service development. Inthe embodiment illustrated herein, the application software program(200, 300, 400 and 700) is written in a combination of Java and C++. Theapplication software (200, 300, 400 and 700) can use Structured QueryLanguage (SQL) for extracting data from the databases and the World WideWeb (5, 6, 7 and 8). The user (40) and manager (41) can optionallyinteract with the user-interface portion of the application software(700) using the browser software (800) in the browser appliance (90) orthrough a natural language interface (714) provided by the MedicineSystem (100) to provide information to the application software (200,300, 400 and 700).

The computers (110) shown in FIG. 5 is a personal computer that iswidely available for use with Linux, Unix or Windows operating systems.Typical memory configurations for client personal computers (110) usedwith the present invention include more than 1024 megabytes ofsemiconductor random access memory (111) and a hard drive (112).

As discussed previously, the Personalized Medicine System (100)completes processing in three distinct stages. As shown in FIG. 6A, FIG.6B and FIG. 6C the first stage of processing (block 200 from FIG. 1)identifies and prepares data from narrow system databases (5); externaldatabases (7); the world wide web (8), external services (9) andoptionally, a partner narrow system database (6) for processing. Thisstage also identifies the entity and entity function and/or missionmeasures. As shown in FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D, FIG. 7E, FIG.7F, FIG. 7G and FIG. 7H, the second stage of processing (block 300 fromFIG. 1) develops and then continually updates a contextbase (50) foreach subject measure. As shown in FIG. 8A and FIG. 8B, the third stageof processing (block 400 from FIG. 1) identifies the valid context spacebefore developing and distributing one or more entity contexts via aPersonalized Medicine System (100). The third stage of processing alsoprepares and prints optional reports. If the operation is continuous,then the processing steps described are repeated continuously. Asdescribed below, one embodiment of the software is a bot or agentarchitecture. Other architectures including a service architecture, ann-tier client server architecture, an integrated applicationarchitecture and combinations thereof can be used to the same effect.

Entity Definition

The flow diagrams in FIG. 6A, FIG. 6B and FIG. 6C detail the processingthat is completed by the portion of the application software (200) thatdefines the subject, identifies the functions and measures for saidsubject, prepares data for use in processing and accepts user (40) andmanagement (41) input. As discussed previously, the system of thepresent invention is capable of accepting data from and transmittingdata to all the narrow systems (4) listed in Tables 4, 5, 6 and 7. Itcan also accept data from and transmit data to the devices listed inTable 8. Data extraction, processing and storage are normally completedby the Personalized Medicine System (100). This data extraction,processing and storage can be facilitated by a separate data integrationlayer in an operating system or middleware application as described incross referenced application Ser. No. 10/748,890. Operation of thePersonalized Medicine System (100) will be illustrated by describing theextraction and use of structured data from a narrow system database (5)for supply chain management and an external database (7). A briefoverview of the information typically obtained from these two databaseswill be presented before reviewing each step of processing completed bythis portion (200) of the application software.

Supply chain systems are one of the narrow systems (4) identified inTable 7. Supply chain databases are a type of narrow system database (5)that contain information that may have been in operation managementsystem databases in the past. These systems provide enhanced visibilityinto the availability of resources and promote improved coordinationbetween subject entities and their supplier entities. All supply chainsystems would be expected to track all of the resources ordered by anentity after the first purchase. They typically store informationsimilar to that shown below in Table 14.

TABLE 14 Supply chain system information  1. Stock Keeping Unit (SKU) 2. Vendor  3. Total quantity on order  4. Total quantity in transit  5.Total quantity on back order  6. Total quantity in inventory  7.Quantity available today  8. Quantity available next 7 days  9. Quantityavailable next 30 days 10. Quantity available next 90 days 11. Quotedlead time 12. Actual average lead time

External databases (7) are used for obtaining information that enablesthe definition and evaluation of words, phrases, context elements,context factors and event risks. In some cases, information from thesedatabases can be used to supplement information obtained from the otherdatabases and the World Wide Web (5, 6 and 8). In the system of thepresent invention, the information extracted from external databases (7)includes the data listed in Table 15.

TABLE 15 External database information 1. Text information such as thatfound in the Lexis Nexis database 2. Text information from databasescontaining past issues of specific publications 3. Multimediainformation such as video and audio clips 4. Idea market prices indicatelikelihood of certain events occurring 5. Event risk data includinginformation about risk proba- bility and magnitude for weather andgeological events 6. Known phonemes and phrases

System processing of the information from the different data sources (3,4, 5, 6, 7, 8 and 9) described above starts in a block 202, FIG. 6A. Thesoftware in block 202 prompts the user (40) via the system settings datawindow (701) to provide system setting information. The system settinginformation entered by the user (40) is stored in the system settingstable (162) in the contextbase (50). The specific inputs the user (40)is asked to provide at this point in processing are shown in Table 16.

TABLE 16  1. Continuous, if yes, calculation frequency? (by minute,hour,day, week, etc.)  2. Subject (patient, group or patient-entity multidomainsystem)  3. SIC Codes  4. Names of primary competitors by SIC Code(if applicable)  5. Base account structure  6. Base units of measure  7.Base currency  8. Risk free interest rate  9. Program bots orapplications? (yes or no) 10. Process measurements? (yes or no) 11.Probabilistic relational models? (yes or no) 12. Knowledge captureand/or collaboration? (yes or no) 13. Natural language interface? (yes,no or voice activated) 14. Video data extraction? (yes or no) 15. Imagedata extraction? (yes or no) 16. Internet data extraction? (yes or no)17. Reference layer? (yes or no, if yes specify coordinate system(s))18. Text data analysis? (yes or no) 19. Geo-coded data? (if yes, thenspecify standard) 20. Maximum number of clusters (default is six) 21.Management report types (text, graphic or both) 22. Default missing dataprocedure (chose from selection) 23. Maximum time to wait for user input24. Maximum number of subelements (optional) 25. Most likely scenario,normal, extreme or mix (default is normal) 26. System time period (days,month, years, decades, light years, etc.) 27. Date range forhistory-forecast time periods (optional) 28. Uncertainty level andsource by narrow system type (optionally, default is zero) 29. Weight ofevidence cutoff level (by context) 30. Time frame(s) for proactivesearch (hours, days, weeks, etc.) 31. Node depth for scouting and/orsearching for data, information and knowledge 32. Impact cutoff forscouting and/or searching for data, information and knowledgeThe system settings data are used by the software in block 202 toestablish context layers. As described previously, there are generallyeight types of context layers for the subject. The application of theremaining system settings will be further explained as part of thedetailed explanation of the system operation. The software in block 202also uses the current system date and the system time period saved inthe system settings table (162) to determine the time periods (generallyin months) where data will be sought to complete the calculations. Theuser (40) also has the option of specifying the time periods that willbe used for system calculations. After the date range is stored in thesystem settings table (162) in the contextbase (50), processing advancesto a software block 203.

The software in block 203 prompts the user (40) via the entity datawindow (702) to identify the subject, identify subject functions andidentify any extensions to the subject hierarchy or hierarchiesspecified in the system settings table (162). For example if theorganism hierarchy (2300) was chosen, the user (40) could extend thehierarchy by specifying a join with the cellular hierarchy (2200). Aspart of the processing in this block, the user (40) is also given theoption to modify the subject hierarchy or hierarchies. If the user (40)elects to modify one or more hierarchies, then the software in the blockwill prompt the user (40) to provide information for use in modifyingthe pre-defined hierarchy metadata in the hierarchy metadata table (155)to incorporate the modifications. The user (40) can also elect to limitthe number of separate levels that are analyzed below the subject in agiven hierarchy. For example, an organization could choose to examinethe impact of their divisions on organization performance by limitingthe context elements to one level below the subject. After the user (40)completes the specification of hierarchy extensions, modifications andlimitations, the software in block 203 selects the appropriate metadatafrom the hierarchy metadata table (155) and establishes the hierarchymetadata (155) and stores the ontology (152) and entity schema (157).The software in block 203 uses the extensions, modifications andlimitations together with three rules for establishing the entityschema:

-   -   1. the members of the entity hierarchy that are above the        subject are factors;    -   2. hierarchies that could be used to extend the entity hierarchy        that are not selected will be excluded; and    -   3. all other hierarchies and groups will be potential factors.        After subject schema is developed, the user (40) is asked to        define process maps and procedures. The maps and procedures        identified by the user (40) are stored in the relationship layer        table (144) in the contextbase (50). The information provided by        the user (40) will be supplemented with information developed        later in the first stage of processing. It is also possible to        obtain relationship layer information concerning process maps        and procedures in an automated fashion by analyzing transaction        patterns or reverse engineering narrow systems (4) as they often        codify the relationship between different context elements,        factors, events, resources and/or actions. The Complete Context™        Capture and Collaboration Service (622) can also be used here to        supplement the information provided by the user (40) with        information from subject matter experts (42). After data storage        is complete, processing advances to a software block 204.

The software in block 204 prompts a context interface window (715) tocommunicate via a network (45) with the different devices (3), systems(4), databases (5, 6, 7), the World Wide Web (8) and external services(9) that are data sources for the Personalized Medicine System (100). Asshown on FIG. 10 the context interface window (715) contains a multiplestep operation where the sequence of steps depends on the nature of theinteraction and the data being provided to the Medicine System (100). Inone embodiment, a data input session would be managed by the a softwareblock (720) that identifies the data source (3, 4, 5, 6, 7, 8 or 9)using standard protocols such as UDDI or xml headers, maintains securityand establishes a service level agreement with the data source (3, 4, 5,6, 7, 8 or 9). The data provided at this point could include transactiondata, descriptive data, imaging data, video data, text data, sensordata, geospatial coordinate data, array data, virtual referencecoordinate data and combinations thereof. The session would proceed to asoftware block (722) for pre-processing such as discretization,transformation and/or filtering. After completing the pre-processing insoftware block 722, processing would advance to a software block (724).The software in that block would determine if the data provided by thedata source (3, 4, 5, 6, 7, 8 or 9) complied with the entity schema orontology using pair-wise similarity measures on several dimensionsincluding terminology, internal structure, external structure,extensions, hierarchical classifications (see Tables 1, 2 and 3) andsemantics. If it did comply, then the data would not require alignmentand the session would advance to a software block (732) where anyconversions to match the base units of measure, currency or time periodspecified in the system settings table (162) would be identified beforethe session advanced to a software block (734) where the location ofthis data would be mapped to the appropriate context layers and storedin the contextbase (50). Establishing a virtual database in this mannereliminates the latency that can cause problems for real time processing.The virtual database information for the element layer for the subjectand context elements is stored in the element layer table (141) in thecontextbase (50). The virtual database information for the resourcelayer for the subject resources is stored in the resource layer table(143) in the contextbase (50). The virtual database information for theenvironment layer for the subject and context factors is stored in theenvironment layer table (149) in the contextbase (50). The virtualdatabase information for the transaction layer for the subject, contextelements, actions and events is stored in the transaction layer table(142) in the contextbase (50). The processing path described in thisparagraph is just one of many paths for processing data input.

As shown FIG. 10, the context interface window (715) has provisions foran alternate data input processing path. This path is used if the dataare not in alignment with the entity schema (157) or ontology (152). Inthis alternate mode, the data input session would still be managed bythe session management software in block (720) that identifies the datasource (3, 4, 5, 6, 7, 8 or 9) maintains security and establishes aservice level agreement with the data source (3, 4, 5, 6, 7, 8 or 9).The session would proceed to the pre-processing software block (722)where the data from one or more data sources (3, 4, 5, 6, 7, 8 or 9)that requires translation and optional analysis is processed beforeproceeding to the next step. The software in block 722 has provisionsfor translating, parsing and other pre-processing of audio, image,micro-array, transaction, video and unformatted text data formats toschema or ontology compliant formats (xml formats in one embodiment).The audio, text and video data are prepared as detailed in crossreferenced patent application Ser. No. 10/717,026. Image translationinvolves conversion, registration, segmentation and segmentidentification using object boundary models. Other image analysisalgorithms can be used to the same effect. Other pre-processing stepscan include discretization and stochastic resonance processing. Afterpre-processing is complete, the session advances to a software block724. The software in block 724 determine whether or not the data was inalignment with the ontology (152) or schema (157) stored in thecontextbase (50) using pair wise comparisons as described previously.Processing then advances to the software in block 736 which uses themappings identified by the software in block 724 together with a seriesof matching algorithms including key properties, similarity, globalnamespace, value pattern and value range algorithms to align the inputdata with the entity schema (157) or ontology (152). Processing, thenadvances to a software block 738 where the metadata associated with thedata are compared with the metadata stored in the subject schema table(157). If the metadata are aligned, then processing is completed usingthe path described previously. Alternatively, if the metadata are stillnot aligned, then processing advances to a software block 740 wherejoins, intersections and alignments between the two schemas orontologies are completed in an automated fashion. Processing thenadvances to a software block 742 where the results of these operationsare compared with the schema (157) or ontology (152) stored in thecontextbase (50). If these operations have created alignment, thenprocessing is completed using the path described previously.Alternatively, if the metadata are still not aligned, then processingadvances to a software block 746 where the schemas and/or ontologies arechecked for partial alignment. If there is partial alignment, thenprocessing advances to a software block 744. Alternatively, if there isno alignment, then processing advances to a software block 747 where thedata are tagged for manual review and stored in the unassigned datatable (146). The software in block 744 cleaves the data in order toseparate the portion that is in alignment from the portion that is notin alignment. The portion of the data that is not in alignment isforwarded to software block 747 where it is tagged for manual alignmentand stored in the unassigned data table (146). The portion of the datathat is in alignment is processed using the path described previously.Processing advances to a block 748 where the user (40) reviews theunassigned data table (146) using the review window (703) to see if theentity schema should be modified to encompass the currently unassigneddata and the changes in the schema (157) and/or ontology (152)—ifany—are saved in the contextbase (50).

After context interface window (715) processing is completed for allavailable data from the devices (3), systems (4), databases (5, 6 and7), the World Wide Web (8), and external services (9), processingadvances to a software block 206 where the software in block 206optionally prompts the context interface window (715) to communicate viaa network (45) with the Complete Context™ Input Service (601). Thecontext interface window (715) uses the path described previously fordata input to map the identified data to the appropriate context layersand store the mapping information in the contextbase (50) as describedpreviously. After storage of the Complete Context™ Input Service (601)data are complete, processing advances to a software block 207.

The software in block 207 prompts the user (40) via the review datawindow (703) to optionally review the context layer data that has beenstored in the first few steps of processing. The user (40) has theoption of changing the data on a one time basis or permanently. Anychanges the user (40) makes are stored in the table for thecorresponding context layer (i.e. transaction layer changes are saved inthe transaction layer table (142), etc.). As part of the processing inthis block, an interactive GEL algorithm prompts the user (40) via thereview data window (703) to check the hierarchy or group assignment ofany new elements, factors and resources that have been identified. Anynewly defined categories are stored in the relationship layer table(144) and the subject schema table (157) in the contextbase (50) beforeprocessing advances to a software block 208.

The software in block 208 prompts the user (40) via the requirement datawindow (710) to optionally identify requirements for the subject.Requirements can take a variety of forms but the two most common typesof requirements are absolute and relative. For example, a requirementthat the level of cash should never drop below $50,000 is an absoluterequirement while a requirement that there should never be less than twomonths of cash on hand is a relative requirement. The user (40) also hasthe option of specifying requirements as a subject function later inthis stage of processing. Examples of different requirements are shownin Table 17.

TABLE 17 Entity Requirement (reason) Individual Stop working at 67(retirement) (1401) Keep blood pressure below 155/95 (health) Availablefunds > $X by Jan. 01, 2014 (college for daughter) Government Foreigncurrency reserves > $X (IMF requirement) Organization 3 functionaldivisions on standby (defense) (1607) Pension assets > liabilities(legal) Circulatory Cholesterol level between 120 and 180 System (2304)Pressure between 110/75 and 150/100The software in this block provides the ability to specify absoluterequirements, relative requirements and standard “requirements” for anyreporting format that is defined for use by the Complete Context™ ReviewService (607)

After requirements are specified, they are stored in the requirementtable (159) in the contextbase (50) by entity before processing advancesto a software block 211.

The software in block 211 checks the unassigned data table (146) in thecontextbase (50) to see if there are any data that has not been assignedto an entity and/or context layer. If there are no data without acomplete assignment (entity and element, resource, factor or transactioncontext layer constitutes a complete assignment), then processingadvances to a software block 214. Alternatively, if there are datawithout an assignment, then processing advances to a software block 212.The software in block 212 prompts the user (40) via the identificationand classification data window (705) to identify the context layer andentity assignment for the data in the unassigned data table (146). Afterassignments have been specified for every data element, the resultingassignments are stored in the appropriate context layer tables in thecontextbase (50) by entity before processing advances to a softwareblock 214.

The software in block 214 checks the element layer table (141), thetransaction layer table (142) and the resource layer table (143) and theenvironment layer table (149) in the contextbase (50) to see if data aremissing for any specified time period. If data are not missing for anytime period, then processing advances to a software block 218.Alternatively, if data for one or more of the specified time periodsidentified in the system settings table (162) for one or more items ismissing from one or more context layers, then processing advances to asoftware block 216. The software in block 216 prompts the user (40) viathe review data window (703) to specify the procedure that will be usedfor generating values for the items that are missing data by timeperiod. Options the user (40) can choose at this point include: theaverage value for the item over the entire time period, the averagevalue for the item over a specified time period, zero or the average ofthe preceding item and the following item values and direct user inputfor each missing value. If the user (40) does not provide input within aspecified interval, then the default missing data procedure specified inthe system settings table (162) is used. When the missing time periodshave been filled and stored for all the items that were missing data,then system processing advances to a block 218.

The software in block 218 retrieves data from the element layer table(141), the transaction layer table (142), the resource layer table (143)and the environment layer table (149). It uses this data to calculateindicators for the data associated with each element, resource andenvironmental factor. The indicators calculated in this step arecomprised of comparisons, regulatory measures and statistics.Comparisons and statistics are derived for: appearance, description,numeric, shape, shape/time and time characteristics. These comparisonsand statistics are developed for different types of data as shown belowin Table 18.

TABLE 18 Characteristic/ Appear- Nu- Shape- Data type ance Descriptionmeric Shape Time Time audio X X X coordinate X X X X X image X X X X Xtext X X X transaction X X video X X X X X X = comparisons andstatistics are developed for these characteristic/data type combinationsNumeric characteristics are pre-assigned to different domains. Numericcharacteristics include amperage, area, concentration, density, depth,distance, growth rate, hardness, height, hops, impedance, level, mass tocharge ratio, nodes, quantity, rate, resistance, similarity, speed,tensile strength, voltage, volume, weight and combinations thereof. Timecharacteristics include frequency measures, gap measures (i.e. timesince last occurrence, average time between occurrences, etc.) andcombinations thereof. The numeric and time characteristics are alsocombined to calculate additional indicators. Comparisons include:comparisons to baseline (can be binary, 1 if above, 0 if below),comparisons to external expectations, comparisons to forecasts,comparisons to goals, comparisons to historical trends, comparisons toknown bad, comparisons to known good, life cycle comparisons,comparisons to normal, comparisons to peers, comparisons to regulations,comparison to requirements, comparisons to a standard, sequencecomparisons, comparisons to a threshold (can be binary, 1 if above, 0 ifbelow) and combinations thereof. Statistics include: averages (mean,median and mode), convexity, copulas, correlation, covariance,derivatives, Pearson correlation coefficients, slopes, trends andvariability. Time lagged versions of each piece of data, statistic andcomparison are also developed. The numbers derived from thesecalculations are collectively referred to as “indicators” (also known asitem performance indicators and factor performance indicators). Thesoftware in block 218 also calculates mathematical and/or logicalcombinations of indicators called composite variables (also known ascomposite factors when associated with environmental factors). Thesecombinations include both pre-defined combinations and derivedcombinations. The AQ program is used for deriving combinations. Itshould be noted that other attribute derivation algorithms, such as theLINUS algorithms, may be used to generate the combinations. Theindicators and the composite variables are tagged and stored in theappropriate context layer table—the element layer table (141), theresource layer table (143) or the environment layer table (149)—beforeprocessing advances to a software block 220.

The software in block 220 checks the bot date table (163) anddeactivates pattern bots with creation dates before the current systemdate and retrieves information from the system settings table (162), theelement layer table (141), the transaction layer table (142), theresource layer table (143) and the environment layer table (149). Thesoftware in block 220 then initializes pattern bots for each layer toidentify patterns in each layer. Bots are independent components of theapplication software of the present invention that complete specifictasks. In the case of pattern bots, their tasks are to identify patternsin the data associated with each context layer. In one embodiment,pattern bots use Apriori algorithms identify patterns including frequentpatterns, sequential patterns and multi-dimensional patterns. However, anumber of other pattern identification algorithms including the slidingwindow algorithm; differential association rule, beam-search, frequentpattern growth, decision trees and the PASCAL algorithm can be usedalone or in combination to the same effect. Every pattern bot containsthe information shown in Table 19.

TABLE 19 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Storagelocation 4. Entity type(s) 5. Entity 6. Context Layer 7. AlgorithmAfter being initialized, the bots identify patterns for the dataassociated with elements, resources, factors and combinations thereof.Each pattern is given a unique identifier and the frequency and type ofeach pattern is determined. The numeric values associated with thepatterns are indicators. The values are stored in the appropriatecontext layer table before processing advances to a software block 222.

The software in block 222 uses causal association algorithms includingLCD, CC and CU to identify causal associations between indicators,composite variables, element data, factor data, resource data andevents, actions, processes and measures. The software in this block usessemantic association algorithms including path length, subsumption,source uncertainty and context weight algorithms to identifyassociations. The identified associations are stored in the causal linktable (148) for possible addition to the relationship layer table (144)before processing advances to a software block 224.

The software in block 224 uses a tournament of petri nets, time warpingalgorithms and stochism algorithms to identify probable subjectprocesses in an automated fashion. Other pathway identificationalgorithms can be used to the same effect. The identified processes arestored in the relationship layer table (144) before processing advancesto a software block 226.

The software in block 226 prompts the user (40) via the review datawindow (703) to optionally review the new associations stored in thecausal link table (148) and the newly identified processes stored in therelationship layer table (144). Associations and/or processes that havealready been specified or approved by the user (40) will not bedisplayed automatically. The user (40) has the option of accepting orrejecting each identified association or process. Any associations orprocesses the user (40) accepts are stored in the relationship layertable (144) before processing advances a software block 242.

The software in block 242 checks the measure layer table (145) in thecontextbase (50) to determine if there are current models for allmeasures for every entity. If all measure models are current, thenprocessing advances to a software block 252. Alternatively, if allmeasure models are not current, then the next measure for the nextentity is selected and processing advances to a software block 244.

The software in block 244 checks the bot date table (163) anddeactivates event risk bots with creation dates before the currentsystem date. The software in the block then retrieves the informationfrom the transaction layer table (142), the relationship layer table(144), the event risk table (156), the subject schema table (157) andthe system settings table (162) in order to initialize event risk botsfor the subject in accordance with the frequency specified by the user(40) in the system settings table (162). Bots are independent componentsof the application software that complete specific tasks. In the case ofevent risk bots, their primary tasks are to forecast the frequency andmagnitude of events that are associated with negative measureperformance in the relationship layer table (144). In addition toforecasting risks that are traditionally covered by insurance such asfires, floods, earthquakes and accidents, the system of the presentinvention also uses the data to forecast standard, “non-insured” eventrisks such as the risk of employee resignation and the risk of customerdefection. The system of the present invention uses a tournamentforecasting method for event risk frequency and duration. The mappinginformation from the relationship layer is used to identify theelements, factors, resources and/or actions that will be affected byeach event. Other forecasting methods can be used to the same effect.Every event risk bot contains the information shown in Table 20.

TABLE 20 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7. Event(fire, flood, earthquake, tornado, accident, defection, etc.)After the event risk bots are initialized they activate in accordancewith the frequency specified by the user (40) in the system settingstable (162). After being activated the bots retrieve the specified dataand forecast the frequency and measure impact of the event risks. Theresulting forecasts are stored in the event risk table (156) beforeprocessing advances to a software block 246.

The software in block 246 checks the bot date table (163) anddeactivates extreme risk bots with creation dates before the currentsystem date. The software in block 246 then retrieves the informationfrom the transaction layer table (142), the relationship layer table(144), the event risk table (156), the subject schema table (157) andthe system settings table (162) in order to initialize extreme risk botsin accordance with the frequency specified by the user (40) in thesystem settings table (162). Bots are independent components of theapplication software that complete specific tasks. In the case ofextreme risk bots, their primary task is to forecast the probability ofextreme events for events that are associated with negative measureperformance in the relationship layer table (144). The extreme risksbots use the Blocks method and the peak over threshold method toforecast extreme risk magnitude and frequency. Other extreme riskalgorithms can be used to the same effect. The mapping information isthen used to identify the elements, factors, resources and/or actionsthat will be affected by each extreme risk. Every extreme risk botactivated in this block contains the information shown in Table 21.

TABLE 21 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or Group 6. Entity 7.Method: blocks or peak over threshold 8. Event (fire, flood, earthquake,tornado, accident, defection, etc.)After the extreme risk bots are initialized, they activate in accordancewith the frequency specified by the user (40) in the system settingstable (162). Once activated, they retrieve the specified information,forecast extreme event risks and map the impacts to the differentelements, factors, resources and/or actions. The extreme event riskinformation is stored in the event risk table (156) in the contextbase(50) before processing advances to a software block 248.

The software in block 248 checks the bot date table (163) anddeactivates competitor risk bots with creation dates before the currentsystem date. The software in block 248 then retrieves the informationfrom the transaction layer table (142), the relationship layer table(144), the event risk table (156), the subject schema table (157) andthe system settings table (162) in order to initialize competitor riskbots in accordance with the frequency specified by the user (40) in thesystem settings table (162). Bots are independent components of theapplication software that complete specific tasks. In the case ofcompetitor risk bots, their primary task is to identify the probabilityof competitor actions and/or events that are associated with negativemeasure performance in the relationship layer table (144). Thecompetitor risk bots use game theoretic real option models to forecastcompetitor risks. Other risk forecasting algorithms can be used to thesame effect. The mapping information is then used to identify theelements, factors, resources and/or actions that will be affected byeach customer risk. Every competitor risk bot activated in this blockcontains the information shown in Table 22.

TABLE 22 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Entity type(s) 6. Entity 7.CompetitorAfter the competitor risk bots are initialized, they retrieve thespecified information and forecast the frequency and magnitude ofcompetitor risks. The bots save the competitor risk information in theevent risk table (156) in the contextbase (50) and processing advancesto a block 250.

The software in block 250 retrieves data from the event risk table (156)and the subject schema table (157) before using a measures data window(704) to display a table showing the distribution of risk impacts byelement, factor, resource and action. After the review of the table iscomplete, the software in block 250 prompts the manager (41) via themeasures data window (704) to specify one or more measures for thesubject. Measures are quantitative indications of subject behavior orperformance. The primary types of behavior are production (includesimprovements and new creations), destruction (includes reductions andcomplete destruction) and maintenance. As discussed previously, themanager (41) is given the option of using pre-defined measures orcreating new measures using terms defined in the subject schema table(157). The measures can combine performance and risk measures or theperformance and risk measures can be kept separate. If more than onemeasure is defined for the subject, then the manager (41) is prompted toassign a weighting or relative priority to the different measures thathave been defined. As system processing advances, the assignedpriorities can be compared to the priorities that entity actionsindicate are most important. The priorities used to guide analysis canbe the stated priorities, the inferred priorities or some combinationthereof. The gap between stated priorities and actual priorities is acongruence measure that can be used in analyzing aspects ofperformance—particularly mental health.

After the specification of measures and priorities has been completed,the values of each of the newly defined measures are calculated usinghistorical data and forecast data. If forecast data are not available,then the Complete Context™ Forecast Service (603) is used to supply themissing values. These values are then stored in the measure layer table(145) along with the measure definitions and priorities. When datastorage is complete, processing advances to a software block 252.

The software in block 252 checks the bot date table (163) anddeactivates forecast update bots with creation dates before the currentsystem date. The software in block 252 then retrieves the informationfrom the system settings table (162) and environment layer table (149)in order to initialize forecast bots in accordance with the frequencyspecified by the user (40) in the system settings table (162). Bots areindependent components of the application software of the presentinvention that complete specific tasks. In the case of forecast updatebots, their task is to compare the forecasts for context factors andwith the information available from futures exchanges (including ideamarkets) and update the existing forecasts. This function is generallyonly used when the system is not run continuously. Every forecast updatebot activated in this block contains the information shown in Table 23.

TABLE 23 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Entity type(s) 6. Entity 7. Contextfactor 8. Measure 9. Forecast time periodAfter the forecast update bots are initialized, they activate inaccordance with the frequency specified by the user (40) in the systemsettings table (162). Once activated, they retrieve the specifiedinformation and determine if any forecasts need to be updated to bringthem in line with the market data. The bots save the updated forecastsin the environment layer table (149) by entity and processing advancesto a software block 254.

The software in block 254 checks the bot date table (163) anddeactivates scenario bots with creation dates before the current systemdate. The software in block 254 then retrieves the information from thesystem settings table (162), the element layer table (141), thetransaction layer table (142), the resource layer table (143), therelationship layer table (144), the environment layer table (149), theevent risk table (156) and the subject schema table (157) in order toinitialize scenario bots in accordance with the frequency specified bythe user (40) in the system settings table (162).

Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of scenariobots, their primary task is to identify likely scenarios for theevolution of the elements, factors, resources and event risks by entity.The scenario bots use the statistics calculated in block 218 togetherwith the layer information retrieved from the contextbase (50) todevelop forecasts for the evolution of the elements, factors, resources,events and actions under normal conditions, extreme conditions and ablended extreme-normal scenario. Every scenario bot activated in thisblock contains the information shown in Table 24.

TABLE 24 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: normal, extreme or blended 6.Entity type(s) 7. Entity 8. MeasureAfter the scenario bots are initialized, they activate in accordancewith the frequency specified by the user (40) in the system settingstable (162). Once activated, they retrieve the specified information anddevelop a variety of scenarios as described previously. After thescenario bots complete their calculations, they save the resultingscenarios in the scenarios table (168) by entity in the contextbase (50)and processing advances to a block 301.

Contextbase Development

The flow diagrams in FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D, FIG. 7E, FIG.7F, FIG. 7G and FIG. 7H detail the processing that is completed by theportion of the application software (300) that continually develops afunction measure oriented contextbase (50) by creating and activatinganalysis bots that:

-   -   1. Supplement the relationship layer (144) information developed        previously by identifying relationships between the elements,        factors, resources, events, actions and one or more measures;    -   2. Complete the measure layer (145) by developing robust models        of the elements, factors, resources, events and/or actions        driving measure performance;    -   3. Develop robust models of the elements, factors, resources and        events driving action and/or event occurrence rates and impact        levels;    -   4. Analyze measures for the subject hierarchy in order to        evaluate alignment and adjust measures in order to achieve        alignment in an automated fashion; and    -   5. Determine the relationship between function and/or mission        measures and subject performance.        Each analysis bot generally normalizes the data being analyzed        before processing begins. As discussed previously, processing in        this embodiment includes an analysis of all measures and        alternative architectures that include a web and/or grid service        architecture. The system of the present invention can combine        any number of measures in order to evaluate the performance of        any entity in the seventeen hierarchies/groups described        previously.

Before discussing this stage of processing in more detail, it will behelpful to review the processing already completed. As discussedpreviously, we are interested developing the complete context for thebehavior of a subject. We will develop this complete context bydeveloping a detailed understanding of the impact of elements,environmental factors, resources, events, actions and other relevantentities on one or more subject function and/or mission measures. Someof the elements and resources may have been grouped together to completeprocesses (a special class of element). The first stage of processingreviewed the data from some or all of the narrow systems (4) listed inTable 4, 5, 6 and 7 and the devices (3) listed in Table 8 andestablished a contextbase (50) that formalized the understanding of theidentity and description of the elements, factors, resources, events andtransactions that impact subject function and/or mission measureperformance. The contextbase (50) also ensures ready access to the dataused for the second and third stages of computation in the PersonalizedMedicine System (100). In the second stage of processing we will use thecontextbase (50) to develop an understanding of the relative impact ofthe different elements, factors, resources, events and transactions onsubject measures.

Because processes rely on elements and resources to produce actions, theuser (40) is given the choice between a process view and an element viewfor measure analysis to avoid double counting. If the user (40) choosesthe element approach, then the process impact can be obtained byallocating element and resource impacts to the processes. Alternatively,if the user (40) chooses the process approach, then the process impactscan be divided by element and resource.

Processing in this portion of the application begins in software block301. The software in block 301 checks the measure layer table (145) inthe contextbase (50) to determine if there are current models for allmeasures for every entity. Measures that are integrated to combine theperformance and risk measures into an overall measure are considered twomeasures for purposes of this evaluation. If all measure models arecurrent, then processing advances to a software block 322.Alternatively, if all measure models are not current, then processingadvances to a software block 302.

The software in block 302 checks the subject schema table (157) in thecontextbase (50) to determine if spatial data is being used. If spatialdata is being used, then processing advances to a software block 341.Alternatively, if all spatial data are not being used, then processingadvances to a software block 303.

The software in block 303 retrieves the previously calculated values forthe next measure from the measure layer table (145) before processingadvances to a software block 304. The software in block 304 checks thebot date table (163) and deactivates temporal clustering bots withcreation dates before the current system date. The software in block 304then initializes bots in accordance with the frequency specified by theuser (40) in the system settings table (162). The bots retrieveinformation from the measure layer table (145) for the entity beinganalyzed and defines regimes for the measure being analyzed beforesaving the resulting cluster information in the relationship layer table(144) in the contextbase (50). Bots are independent components of theapplication software of the present invention that complete specifictasks. In the case of temporal clustering bots, their primary task is tosegment measure performance into distinct time regimes that sharesimilar characteristics. The temporal clustering bot assigns a uniqueidentification (id) number to each “regime” it identifies before taggingand storing the unique id numbers in the relationship layer table (144).Every time period with data are assigned to one of the regimes. Thecluster id for each regime is associated with the measure and entitybeing analyzed. The time regimes are developed using a competitiveregression algorithm that identifies an overall, global model beforesplitting the data and creating new models for the data in eachpartition. If the error from the two models is greater than the errorfrom the global model, then there is only one regime in the data.Alternatively, if the two models produce lower error than the globalmodel, then a third model is created. If the error from three models islower than from two models then a fourth model is added. The processingcontinues until adding a new model does not improve accuracy. Othertemporal clustering algorithms may be used to the same effect. Everytemporal clustering bot contains the information shown in Table 25.

TABLE 25 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Maximum number of clusters 6. Entitytype(s) 7. Entity 8. MeasureWhen bots in block 304 have identified and stored regime assignments forall time periods with measure data for the current entity, processingadvances to a software block 305.

The software in block 305 checks the bot date table (163) anddeactivates variable clustering bots with creation dates before thecurrent system date. The software in block 305 then initializes bots inorder for each element, resource and factor for the current entity. Thebots activate in accordance with the frequency specified by the user(40) in the system settings table (162), retrieve the information fromthe element layer table (141), the transaction layer table (142), theresource layer table (143), the environment layer table (149) and thesubject schema table (157) in order and define segments for element,resource and factor data before tagging and saving the resulting clusterinformation in the relationship layer table (144).

Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of variableclustering bots, their primary task is to segment the element, resourceand factor data—including performance indicators—into distinct clustersthat share similar characteristics. The clustering bot assigns a uniqueid number to each “cluster” it identifies, tags and stores the unique idnumbers in the relationship layer table (144). Every item variable foreach element, resource and factor is assigned to one of the uniqueclusters. The element data, resource data and factor data are segmentedinto a number of clusters less than or equal to the maximum specified bythe user (40) in the system settings table (162). The data are segmentedusing several clustering algorithms including: an unsupervised “Kohonen”neural network, decision tree, context distance, support vector method,K-nearest neighbor, expectation maximization (EM) and the segmentalK-means algorithm. For algorithms that normally use the specified numberof clusters the bot will use the maximum number of clusters specified bythe user (40) in the system settings table (162). Every variableclustering bot contains the information shown in Table 26.

TABLE 26  1. Unique ID number (based on date, hour, minute, second ofcreation)  2. Creation date (date, hour, minute, second)  3. Mappinginformation  4. Storage location  5. Context component  6. Clusteringalgorithm type  7. Entity type(s)  8. Entity  9. Measure 10. Maximumnumber of clusters 11. Variable 1 . . . to 11 + n. Variable nWhen bots in block 305 have identified, tagged and stored clusterassignments for the data associated with every element, resource andfactor in the relationship layer table (144), processing advances to asoftware block 307.

The software in block 307 checks the measure layer table (145) in thecontextbase (50) to see if the current measure is an options basedmeasure like contingent liabilities, real options or competitor risk. Ifthe current measure is not an options based measure, then processingadvances to a software block 309. Alternatively, if the current measureis an options based measure, then processing advances to a softwareblock 308.

The software in block 308 checks the bot date table (163) anddeactivates option bots with creation dates before the current systemdate. The software in block 308 then retrieves the information from thesystem settings table (162), the subject schema table (157) and theelement layer table (141), the transaction layer table (142), theresource layer table (143), the relationship layer table (144), theenvironment layer table (149) and the scenarios table (168) in order toinitialize option bots in accordance with the frequency specified by theuser (40) in the system settings table (162).

Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of optionbots, their primary task is to determine the impact of each element,resource and factor on the entity option measure under differentscenarios. The option simulation bots run a normal scenario, an extremescenario and a combined scenario with and without clusters. In oneembodiment, Monte Carlo models are used to complete the probabilisticsimulation, however other option models including binomial models,multinomial models and dynamic programming can be used to the sameeffect. The element, resource and factor impacts on option measurescould be determined using the process detailed below for the other typesof measures. However, in the one preferred embodiment being describedherein, a separate procedure is used. Every option bot activated in thisblock contains the information shown in Table 27.

TABLE 27  1. Unique ID number (based on date, hour, minute, second ofcreation)  2. Creation date (date, hour, minute, second)  3. Mappinginformation  4. Storage location  5. Scenario: normal, extreme orcombined  6. Option type: real option, contingent liability orcompetitor risk  7. Entity type(s)  8. Entity  9. Measure 10. Clustereddata? (yes or no) 11. AlgorithmAfter the option bots are initialized, they activate in accordance withthe frequency specified by the user (40) in the system settings table(162). Once activated, the bots retrieve the specified information andsimulate the measure over the time periods specified by the user (40) inthe system settings table (162) in order to determine the impact of eachelement, resource and factor on the option. After the option botscomplete their calculations, the impacts and sensitivities for theoption (clustered data—yes or no) that produced the best result undereach scenario are saved in the measure layer table (145) in thecontextbase (50) and processing returns to software block 301.

If the current measure was not an option measure, then processingadvanced to software block 309. The software in block 309 checks the botdate table (163) and deactivates all predictive model bots with creationdates before the current system date. The software in block 309 thenretrieves the information from the system settings table (162), thesubject schema table (157), the element layer table (141), thetransaction layer table (142), the resource layer table (143), therelationship layer table (144) and the environment layer table (149) inorder to initialize predictive model bots for each measure layer.

Bots are independent components of the application software thatcomplete specific tasks. In the case of predictive model bots, theirprimary task is to determine the relationship between the indicators andthe one or more measures being evaluated. Predictive model bots areinitialized for each cluster and regime of data in accordance with thecluster and regime assignments specified by the bots in blocks 304 and305. A series of predictive model bots is initialized at this stagebecause it is impossible to know in advance which predictive model typewill produce the “best” predictive model for the data from each entity.The series for each model includes: neural network, CART, GARCH,constraint net, projection pursuit regression, stepwise regression,logistic regression, probit regression, factor analysis, growthmodeling, linear regression, redundant regression network, boosted NaiveBayes Regression, support vector method, markov models, kriging,multivalent models, Gillespie models, relevance vector method, MARS,rough-set analysis and generalized additive model (GAM). Other typespredictive models can be used to the same effect. Every predictive modelbot contains the information shown in Table 28.

TABLE 28 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Entity type(s) 6. Entity 7. Measure8. Type: cluster, regime, cluster & regime 9. Predictive model typeAfter predictive model bots are initialized, the bots activate inaccordance with the frequency specified by the user (40) in the systemsettings table (162). Once activated, the bots retrieve the specifieddata from the appropriate table in the contextbase (50) and randomlypartition the element, resource or factor data into a training set and atest set. The software in block 309 uses “bootstrapping” where thedifferent training data sets are created by re-sampling with replacementfrom the original training set so data records may occur more than once.Training with genetic algorithms can also be used. After the predictivemodel bots in the tournament complete their training and testing, thebest fit predictive model assessments of element, resource and factorimpacts on measure performance are saved in the measure layer table(145) before processing advances to a block 310.

The software in block 310 determines if clustering improved the accuracyof the predictive models generated by the bots in software block 309 byentity. The software in block 310 uses a variable selection algorithmsuch as stepwise regression (other types of variable selectionalgorithms can be used) to combine the results from the predictive modelbot analyses for each type of analysis—with and without clustering—todetermine the best set of variables for each type of analysis. The typeof analysis having the smallest amount of error as measured by applyingthe root mean squared error algorithm to the test data is givenpreference in determining the best set of variables for use in lateranalysis. Other error algorithms including entropy measures may also beused. There are four possible outcomes from this analysis as shown inTable 29.

TABLE 29 1. Best model has no clustering 2. Best model has temporalclustering, no variable clustering 3. Best model has variableclustering, no temporal clustering 4. Best model has temporal clusteringand variable clusteringIf the software in block 310 determines that clustering improves theaccuracy of the predictive models for an entity, then processingadvances to a software block 314. Alternatively, if clustering does notimprove the overall accuracy of the predictive models for an entity,then processing advances to a software block 312.

The software in block 312 uses a variable selection algorithm such asstepwise regression (other types of variable selection algorithms can beused) to combine the results from the predictive model bot analyses foreach model to determine the best set of variables for each model. Themodels having the smallest amount of error, as measured by applying theroot mean squared error algorithm to the test data, are given preferencein determining the best set of variables. Other error algorithmsincluding entropy measures may also be used. As a result of thisprocessing, the best set of variables contain the variables (akaelement, resource and factor data), indicators and composite variablesthat correlate most strongly with changes in the measure being analyzed.The best set of variables will hereinafter be referred to as the“performance drivers”.

Eliminating low correlation factors from the initial configuration ofthe vector creation algorithms increases the efficiency of the nextstage of system processing. Other error algorithms including entropymeasures may be substituted for the root mean squared error algorithm.After the best set of variables have been selected, tagged and stored inthe relationship layer table (144) for each entity, the software inblock 312 tests the independence of the performance drivers for eachentity before processing advances to a block 313.

The software in block 313 checks the bot date table (163) anddeactivates causal predictive model bots with creation dates before thecurrent system date. The software in block 313 then retrieves theinformation from the system settings table (162), the subject schematable (157), the element layer table (141), the transaction layer table(142), the resource layer table (143), the relationship layer table(144) and the environment layer table (149) in order to initializecausal predictive model bots for each element, resource and factor inaccordance with the frequency specified by the user (40) in the systemsettings table (162). Sub-context elements, resources and factors may beused in the same manner.

Bots are independent components of the application software thatcomplete specific tasks. In the case of causal predictive model bots,their primary task is to refine the performance driver selection toreflect only causal variables. A series of causal predictive model botsare initialized at this stage because it is impossible to know inadvance which causal predictive model will produce the “best” vector forthe best fit variables from each model. The series for each modelincludes a number of causal predictive model bot types: Tetrad, MML,LaGrange, Bayesian, Probabilistic Relational Model (if allowed), ImpactFactor Majority and path analysis. The Bayesian bots in this step alsorefine the estimates of element, resource and/or factor impact developedby the predictive model bots in a prior processing step by assigning aprobability to the impact estimate. The software in block 313 generatesthis series of causal predictive model bots for each set of performancedrivers stored in the relationship layer table (144) in the previousstage in processing. Every causal predictive model bot activated in thisblock contains the information shown in Table 30.

TABLE 30 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Causal predictive model type 6.Entity type(s) 7. Entity 8. MeasureAfter the causal predictive model bots are initialized by the softwarein block 313, the bots activate in accordance with the frequencyspecified by the user (40) in the system settings table (162). Onceactivated, they retrieve the specified information for each model andsub-divide the variables into two sets, one for training and one fortesting. After the causal predictive model bots complete theirprocessing for each model, the software in block 313 uses a modelselection algorithm to identify the model that best fits the data. Forthe system of the present invention, a cross validation algorithm isused for model selection. The software in block 313 then saves therefined impact estimates in the measure layer table (145) and the bestfit causal element, resource and/or factor indicators are identified inthe relationship layer table (144) in the contextbase (50) beforeprocessing returns to software block 301.

If software in block 310 determines that clustering improves predictivemodel accuracy, then processing advances directly to block 314 asdescribed previously. The software in block 314 uses a variableselection algorithm such as stepwise regression (other types of variableselection algorithms can be used) to combine the results from thepredictive model bot analyses for each model, cluster and/or regime todetermine the best set of variables for each model. The models havingthe smallest amount of error as measured by applying the root meansquared error algorithm to the test data are given preference indetermining the best set of variables. Other error algorithms includingentropy measures may also be used. As a result of this processing, thebest set of variables contains: the element data and factor data thatcorrelate most strongly with changes in the function measure. The bestset of variables will hereinafter be referred to as the “performancedrivers”. Eliminating low correlation factors from the initialconfiguration increases the efficiency of the next stage of systemprocessing. Other error algorithms including entropy measures may besubstituted for the root mean squared error algorithm. After the bestset of variables have been selected, they are tagged as performancedrivers and stored in the relationship layer table (144), the softwarein block 314 tests the independence of the performance drivers beforeprocessing advances to a block 315.

The software in block 315 checks the bot date table (163) anddeactivates causal predictive model bots with creation dates before thecurrent system date. The software in block 315 then retrieves theinformation from the system settings table (162), the subject schematable (157), the element layer table (141), the transaction layer table(142), the resource layer table (143), the relationship layer table(144) and the environment layer table (149) in order to initializecausal predictive model bots in accordance with the frequency specifiedby the user (40) in the system settings table (162). Bots areindependent components of the application software of the presentinvention that complete specific tasks. In the case of causal predictivemodel bots, their primary task is to refine the element, resource andfactor performance driver selection to reflect only causal variables.(Note: these variables are grouped together to represent a singleelement vector when they are dependent). In some cases it may bepossible to skip the correlation step before selecting causal itemvariables, factor variables, indicators, and composite variables. Aseries of causal predictive model bots are initialized at this stagebecause it is impossible to know in advance which causal predictivemodel will produce the “best” vector for the best fit variables fromeach model. The series for each model includes: Tetrad, LaGrange,Bayesian, Probabilistic Relational Model and path analysis. The Bayesianbots in this step also refine the estimates of element or factor impactdeveloped by the predictive model bots in a prior processing step byassigning a probability to the impact estimate. The software in block315 generates this series of causal predictive model bots for each setof performance drivers stored in the subject schema table (157) in theprevious stage in processing. Every causal predictive model botactivated in this block contains the information shown in Table 31.

TABLE 31 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: cluster, regime, cluster &regime 5. Entity type(s) 6. Entity 7. Measure 8. Causal predictive modeltypeAfter the causal predictive model bots are initialized by the softwarein block 315, the bots activate in accordance with the frequencyspecified by the user (40) in the system settings table (162). Onceactivated, they retrieve the specified information for each model andsubdivide the variables into two sets, one for training and one fortesting. The same set of training data are used by each of the differenttypes of bots for each model. After the causal predictive model botscomplete their processing for each model, the software in block 315 usesa model selection algorithm to identify the model that best fits thedata for each element, resource and factor being analyzed by modeland/or regime by entity. For the system of the present invention, across validation algorithm is used for model selection. The software inblock 315 saves the refined impact estimates in the measure layer table(145) and identifies the best fit causal element, resource and/or factorindicators in the relationship layer table (144) in the contextbase (50)before processing returns to software block 301.

When the software in block 301 determines that all measure models arecurrent, then processing advances to a software block 322. The softwarein block 322 checks the measure layer table (145) and the event modeltable (158) in the contextbase (50) to determine if all event models arecurrent. If all event models are current, then processing advances to asoftware block 332. Alternatively, if new event models need to bedeveloped, then processing advances to a software block 325. Thesoftware in block 325 retrieves information from the system settingstable (162), the subject schema table (157), the element layer table(141), the transaction layer table (142), the resource layer table(143), the relationship layer table (144), the environment layer table(149) and the event model table (158) in order to complete summaries ofevent history and forecasts before processing advances to a softwareblock 304 where the processing sequence described above (save for theoption bot processing)—is used to identify drivers for event frequency.After all event frequency models have been developed they are stored inthe event model table (158), processing advances to a software block332.

The software in block 332 checks the measure layer table (145) andimpact model table (166) in the contextbase (50) to determine if impactmodels are current for all event risks and transactions. If all impactmodels are current, then processing advances to a software block 341.Alternatively, if new impact models need to be developed, thenprocessing advances to a software block 335. The software in block 335retrieves information from the system settings table (162), the subjectschema table (157), the element layer table (141), the transaction layertable (142), the resource layer table (143), the relationship layertable (144), the environment layer table (149) and the impact modeltable (166) in order to complete summaries of impact history andforecasts before processing advances to a software block 304 where theprocessing sequence described above—save for the option botprocessing—is used to identify drivers for event and action impact (ormagnitude). After impact models have been developed for all event risksand transaction impacts they are stored in the impact model table (166)and processing advances to a software block 341.

If a spatial coordinate system is being used, then processing advancesto a block 341 before the processing described above begins. Thesoftware in block 341 checks the subject schema table (157) in thecontextbase (50) to determine if spatial data is being used. If spatialdata is being used, then processing advances to a software block 342.Alternatively, if all spatial data are not being used, then processingadvances to a software block 370.

The software in block 342 checks the measure layer table (145) in thecontextbase (50) to determine if there are current models for allspatial measures for every entity level. If all measure models arecurrent, then processing advances to a software block 356.Alternatively, if all spatial measure models are not current, thenprocessing advances to a software block 303. The software in block 303retrieves the previously calculated values for the measure from themeasure layer table (145) before processing advances to software block304.

The software in block 304 checks the bot date table (163) anddeactivates temporal clustering bots with creation dates before thecurrent system date. The software in block 304 then initializes bots inaccordance with the frequency specified by the user (40) in the systemsettings table (162). The bots retrieve information from the measurelayer table (145) for the entity being analyzed and defines regimes forthe measure being analyzed before saving the resulting clusterinformation in the relationship layer table (144) in the contextbase(50). Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of temporalclustering bots, their primary task is to segment measure performanceinto distinct time regimes that share similar characteristics. Thetemporal clustering bot assigns a unique identification (id) number toeach “regime” it identifies before tagging and storing the unique idnumbers in the relationship layer table (144). Every time period withdata is assigned to one of the regimes. The cluster id for each regimeis associated with the measure and entity being analyzed. The timeregimes are developed using a competitive regression algorithm thatidentifies an overall, global model before splitting the data andcreating new models for the data in each partition. If the error fromthe two models is greater than the error from the global model, thenthere is only one regime in the data. Alternatively, if the two modelsproduce lower error than the global model, then a third model iscreated. If the error from three models is lower than from two modelsthen a fourth model is added. The processing continues until adding anew model does not improve accuracy. Other temporal clusteringalgorithms may be used to the same effect. Every temporal clustering botcontains the information shown in Table 32.

TABLE 32 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Maximum number of clusters 6. Entitytype(s) 7. Entity 8. MeasureWhen bots in block 304 have identified and stored regime assignments forall time periods with measure data for the current entity, processingadvances to a software block 305.

The software in block 305 checks the bot date table (163) anddeactivates variable clustering bots with creation dates before thecurrent system date. The software in block 305 then initializes bots inorder for each context element, resource and factor for the currententity level. The bots activate in accordance with the frequencyspecified by the user (40) in the system settings table (162), retrievethe information from the element layer table (141), the transactionlayer table (142), the resource layer table (143), the environment layertable (149) and the subject schema table (157) and define segments forcontext element, resource and factor data before tagging and saving theresulting cluster information in the relationship layer table (144).Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of variableclustering bots, their primary task is to segment the element, resourceand factor data—including indicators—into distinct clusters that sharesimilar characteristics. The clustering bot assigns a unique id numberto each “cluster” it identifies, tags and stores the unique id numbersin the relationship layer table (144). Every variable for every contextelement, resource and factor is assigned to one of the unique clusters.The element data, resource data and factor data are segmented into anumber of clusters less than or equal to the maximum specified by theuser (40) in the system settings table (162). The data are segmentedusing several clustering algorithms including: an unsupervised “Kohonen”neural network, decision tree, support vector method, K-nearestneighbor, expectation maximization (EM) and the segmental K-meansalgorithm. For algorithms that normally have the number of clustersspecified by a user, the bot will use the maximum number of clustersspecified by the user (40). Every variable clustering bot contains theinformation shown in Table 33.

TABLE 33  1. Unique ID number (based on date, hour, minute, second ofcreation)  2. Creation date (date, hour, minute, second)  3. Mappinginformation  4. Storage location  5. Context component  6. Clusteringalgorithm  7. Entity type(s)  8. Entity  9. Measure 10. Maximum numberof clusters 11. Variable 1 . . . to 11 + n. Variable nWhen bots in block 305 have identified, tagged and stored clusterassignments for the data associated with every element, resource andfactor in the relationship layer table (144), processing advances to asoftware block 343.

The software in block 343 checks the bot date table (163) anddeactivates spatial clustering bots with creation dates before thecurrent system date. The software in block 343 then retrieves theinformation from the system settings table (162), the subject schematable (157), the element layer table (141), the transaction layer table(142), the resource layer table (143), the relationship layer table(144), the environment layer table (149), the reference layer table(154) and the scenarios table (168) in order to initialize spatialclustering bots in accordance with the frequency specified by the user(40) in the system settings table (162). Bots are independent componentsof the application software that complete specific tasks. In the case ofspatial clustering bots, their primary task is to segment the element,resource and factor data—including performance indicators—into distinctclusters that share similar characteristics. The clustering bot assignsa unique id number to each “cluster” it identifies, tags and stores theunique id numbers in the relationship layer table (144). Data for eachcontext element, resource and factor are assigned to one of the uniqueclusters. The element, resource and factor data are segmented into anumber of clusters less than or equal to the maximum specified by theuser (40) in the system settings table (162). The system of the presentinvention uses several spatial clustering algorithms including:hierarchical clustering, cluster detection, k-ary clustering, varianceto mean ratio, lacunarity analysis, pair correlation, join correlation,mark correlation, fractal dimension, wavelet, nearest neighbor, localindex of spatial association (LISA), spatial analysis by distanceindices (SADIE), mantel test and circumcircle. Every spatial clusteringbot activated in this block contains the information shown in Table 34.

TABLE 34  1. Unique ID number (based on date, hour, minute, second ofcreation)  2. Creation date (date, hour, minute, second)  3. Mappinginformation  4. Storage location  5. Context component  6. Clusteringalgorithm  7. Entity type(s)  8. Entity  9. Measure 10. Maximum numberof clusters 11. Variable 1 . . . to 11 + n. Variable nWhen bots in block 343 have identified, tagged and stored clusterassignments for the data associated with every element, resource andfactor in the relationship layer table (144), processing advances to asoftware block 307.

The software in block 307 checks the measure layer table (145) in thecontextbase (50) to see if the current measure is an options basedmeasure like contingent liabilities, real options or competitor risk. Ifthe current measure is not an options based measure, then processingadvances to a software block 344. Alternatively, if the current measureis an options based measure, then processing advances to a softwareblock 308.

The software in block 308 checks the bot date table (163) anddeactivates option bots with creation dates before the current systemdate. The software in block 308 then retrieves the information from thesystem settings table (162), the subject schema table (157), the elementlayer table (141), the transaction layer table (142), the resource layertable (143), the relationship layer table (144), the environment layertable (149), the reference layer table (154) and the scenarios table(168) in order to initialize option bots in accordance with thefrequency specified by the user (40) in the system settings table (162).

Bots are independent components of the application software of thepresent invention that complete specific tasks. In the case of optionbots, their primary task is to determine the impact of each element,resource and factor on the entity option measure under differentscenarios. The option simulation bots run a normal scenario, an extremescenario and a combined scenario with and without clusters. In oneembodiment, Monte Carlo models are used to complete the probabilisticsimulation. However, other option models including binomial models,multinomial models and dynamic programming can be used to the sameeffect. The element, resource and factor impacts on option measurescould be determined using the processed detailed below for the othertypes of measures, however, in this embodiment a separate procedure isused. The models are initialized with specifications used in thebaseline calculations. Every option bot activated in this block containsthe information shown in Table 35.

TABLE 35 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Scenario: normal, extreme or combined6. Option type: real option, contingent liability or competitor risk 7.Entity type(s) 8. Entity 9. Measure 10. Clustered data? (Yes or No) 11.AlgorithmAfter the option bots are initialized, they activate in accordance withthe frequency specified by the user (40) in the system settings table(162). Once activated, the bots retrieve the specified information andsimulate the measure over the time periods specified by the user (40) inthe system settings table (162) in order to determine the impact of eachelement, resource and factor on the option. After the option botscomplete their calculations, the impacts and sensitivities for theoption (clustered data—yes or no) that produced the best result undereach scenario are saved in the measure layer table (145) in thecontextbase (50) and processing returns to software block 341.

If the current measure was not an option measure, then processingadvanced to software block 344. The software in block 309 checks the botdate table (163) and deactivates all predictive model bots with creationdates before the current system date. The software in block 344 thenretrieves the information from the system settings table (162), thesubject schema table (157) and the element layer table (141), thetransaction layer table (142), the resource layer table (143), therelationship layer table (144), the environment layer table (149) andthe reference layer (154) in order to initialize predictive model botsfor the measure being evaluated.

Bots are independent components of the application software thatcomplete specific tasks. In the case of predictive model bots, theirprimary task is to determine the relationship between the indicators andthe measure being evaluated. Predictive model bots are initialized foreach cluster and/or regime of data in accordance with the cluster and/orregime assignments specified by the bots in blocks 304, 305 and 343. Aseries of predictive model bots is initialized at this stage because itis impossible to know in advance which predictive model type willproduce the “best” predictive model for the data from each entity. Theseries for each model includes: neural network, CART, GARCH, projectionpursuit regression, stepwise regression, logistic regression, probitregression, factor analysis, growth modeling, linear regression,redundant regression network, boosted naive bayes regression, supportvector method, markov models, rough-set analysis, kriging, simulatedannealing, latent class models, gaussian mixture models, triangulatedprobability and kernel estimation. Each model includes spatialautocorrelation indicators as performance indicators. Other typespredictive models can be used to the same effect. Every predictive modelbot contains the information shown in Table 36.

TABLE 36 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Entity type(s) 6. Entity 7. Measure8. Type: variable (y or n), spatial (y or n), spatial-temporal (y or n)9. Predictive model typeAfter predictive model bots are initialized, the bots activate inaccordance with the frequency specified by the user (40) in the systemsettings table (162). Once activated, the bots retrieve the specifieddata from the appropriate table in the contextbase (50) and randomlypartition the element, resource and/or factor data into a training setand a test set. The software in block 344 uses “bootstrapping” where thedifferent training data sets are created by re-sampling with replacementfrom the original training set so data records may occur more than once.Training with genetic algorithms can also be used. After the predictivemodel bots complete their training and testing, the best fit predictivemodel assessments of element, resource and factor impacts on measureperformance are saved in the measure layer table (145) before processingadvances to a block 345.

The software in block 345 determines if clustering improved the accuracyof the predictive models generated by the bots in software block 344.The software in block 345 uses a variable selection algorithm such asstepwise regression (other types of variable selection algorithms can beused) to combine the results from the predictive model bot analyses foreach type of analysis—with and without clustering—to determine the bestset of variables for each type of analysis. The type of analysis havingthe smallest amount of error as measured by applying the root meansquared error algorithm to the test data are given preference indetermining the best set of variables for use in later analysis. Othererror algorithms including entropy measures may also be used. There areeight possible outcomes from this analysis as shown in Table 37.

TABLE 37 1. Best model has no clustering 2. Best model has temporalclustering, no variable clustering, no spatial clustering 3. Best modelhas variable clustering, no temporal clustering, no spatial clustering4. Best model has temporal clustering, variable clustering, no spatialclustering 5. Best model has no temporal clustering, no variableclustering, spatial clustering 6. Best model has temporal clustering, novariable clustering, spatial clustering 7. Best model has variableclustering, no temporal clustering, spatial clustering 8. Best model hastemporal clustering, variable clustering, spatial clusteringIf the software in block 345 determines that clustering improves theaccuracy of the predictive models for an entity, then processingadvances to a software block 348. Alternatively, if clustering does notimprove the overall accuracy of the predictive models for an entity,then processing advances to a software block 346.

The software in block 346 uses a variable selection algorithm such asstepwise regression (other types of variable selection algorithms can beused) to combine the results from the predictive model bot analyses foreach model to determine the best set of variables for each model. Themodels having the smallest amount of error, as measured by applying theroot mean squared error algorithm to the test data, are given preferencein determining the best set of variables. Other error algorithmsincluding entropy measures may also be used. As a result of thisprocessing, the best set of variables contain the variables (akaelement, resource and factor data), indicators, and composite variablesthat correlate most strongly with changes in the measure being analyzed.The best set of variables will hereinafter be referred to as the“performance drivers”.

Eliminating low correlation factors from the initial configuration ofthe vector creation algorithms increases the efficiency of the nextstage of system processing. Other error algorithms including entropymeasures may be substituted for the root mean squared error algorithm.After the best set of variables have been selected, tagged and stored inthe relationship layer table (144) for each entity level, the softwarein block 346 tests the independence of the performance drivers for eachentity level before processing advances to a block 347.

The software in block 347 checks the bot date table (163) anddeactivates causal predictive model bots with creation dates before thecurrent system date. The software in block 347 then retrieves theinformation from the system settings table (162), the subject schematable (157), the element layer table (141), the transaction layer table(142), the resource layer table (143), the relationship layer table(144) and the environment layer table (149) in order to initializecausal predictive model bots for each element, resource and factor inaccordance with the frequency specified by the user (40) in the systemsettings table (162). Sub-context elements, resources and factors may beused in the same manner.

Bots are independent components of the application software thatcomplete specific tasks. In the case of causal predictive model bots,their primary task is to refine the performance driver selection toreflect only causal variables. A series of causal predictive model botsare initialized at this stage because it is impossible to know inadvance which causal predictive model will produce the “best” fit forvariables from each model. The series for each model includes six causalpredictive model bot types: kriging, latent class models, gaussianmixture models, kernel estimation and Markov-Bayes. The software inblock 347 generates this series of causal predictive model bots for eachset of performance drivers stored in the relationship layer table (144)in the previous stage in processing. Every causal predictive model botactivated in this block contains the information shown in Table 38.

TABLE 38 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Causal predictive model type 6.Entity type(s) 7. Entity 8. MeasureAfter the causal predictive model bots are initialized by the softwarein block 347, the bots activate in accordance with the frequencyspecified by the user (40) in the system settings table (162). Onceactivated, they retrieve the specified information for each model andsub-divide the variables into two sets, one for training and one fortesting. After the causal predictive model bots complete theirprocessing for each model, the software in block 347 uses a modelselection algorithm to identify the model that best fits the data. Forthe system of the present invention, a cross validation algorithm isused for model selection. The software in block 347 then saves therefined impact estimates in the measure layer table (145) and the bestfit causal element, resource and/or factor indicators are identified inthe relationship layer table (144) in the contextbase (50) beforeprocessing returns to software block 342.

If software in block 345 determines that clustering improves predictivemodel accuracy, then processing advances directly to block 348 asdescribed previously. The software in block 348 uses a variableselection algorithm such as stepwise regression (other types of variableselection algorithms can be used) to combine the results from thepredictive model bot analyses for each model, cluster and/or regime todetermine the best set of variables for each model. The models havingthe smallest amount of error as measured by applying the root meansquared error algorithm to the test data are given preference indetermining the best set of variables. Other error algorithms includingentropy measures can also be used. As a result of this processing, thebest set of variables contains the element data, resource data andfactor data that correlate most strongly with changes in the functionand/or mission measures. The best set of variables will hereinafter bereferred to as the “performance drivers”. Eliminating low correlationfactors from the initial configuration of the vector creation algorithmsincreases the efficiency of the next stage of system processing. Othererror algorithms including entropy measures may be substituted for theroot mean squared error algorithm. After the best set of variables havebeen selected, they are tagged as performance drivers and stored in therelationship layer table (144), the software in block 348 tests theindependence of the performance drivers before processing advances to ablock 349.

The software in block 349 checks the bot date table (163) anddeactivates causal predictive model bots with creation dates before thecurrent system date. The software in block 349 then retrieves theinformation from the system settings table (162), the subject schematable (157), the element layer table (141), the transaction layer table(142), the resource layer table (143), the relationship layer table(144) and the environment layer table (149) in order to initializecausal predictive model bots in accordance with the frequency specifiedby the user (40) in the system settings table (162). Bots areindependent components of the application software of the presentinvention that complete specific tasks. In the case of causal predictivemodel bots, their primary task is to refine the element, resource andfactor performance driver selection to reflect only causal variables.(Note: these variables are grouped together to represent a single vectorwhen they are dependent). In some cases it may be possible to skip thecorrelation step before selecting causal the item variables, factorvariables, indicators and composite variables. A series of causalpredictive model bots are initialized at this stage because it isimpossible to know in advance which causal predictive model will producethe “best” fit variables for each measure. The series for each measureincludes six causal predictive model bot types: kriging, latent classmodels, gaussian mixture models, kernel estimation and Markov-Bayes. Thesoftware in block 349 generates this series of causal predictive modelbots for each set of performance drivers stored in the subject schematable (157) in the previous stage in processing. Every causal predictivemodel bot activated in this block contains the information shown inTable 39.

TABLE 39 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: cluster, regime, cluster &regime 6. Entity type(s) 7. Entity 8. Measure 9. Causal predictive modeltypeAfter the causal predictive model bots are initialized by the softwarein block 349, the bots activate in accordance with the frequencyspecified by the user (40) in the system settings table (162). Onceactivated, they retrieve the specified information for each model andsub-divide the variables into two sets, one for training and one fortesting. The same set of training data is used by each of the differenttypes of bots for each model. After the causal predictive model botscomplete their processing for each model, the software in block 349 usesa model selection algorithm to identify the model that best fits thedata for each process, element, resource and/or factor being analyzed bymodel and/or regime by entity. For the system of the present invention,a cross validation algorithm is used for model selection. The softwarein block 349 saves the refined impact estimates in the measure layertable (145) and identifies the best fit causal element, resource and/orfactor indicators in the relationship layer table (144) in thecontextbase (50) before processing returns to software block 342.

When the software in block 342 determines that all spatial measuremodels are current processing advances to a software block 356. Thesoftware in block 356 checks the measure layer table (145) and the eventmodel table (158) in the contextbase (50) to determine if all eventmodels are current. If all event models are current, then processingadvances to a software block 361. Alternatively, if new event modelsneed to be developed, then processing advances to a software block 325.The software in block 325 retrieves information from the system settingstable (162), the subject schema table (157), the element layer table(141), the transaction layer table (142), the resource layer table(143), the relationship layer table (144), the environment layer table(149), the reference layer table (154) and the event model table (158)in order to complete summaries of event history and forecasts beforeprocessing advances to a software block 304 where the processingsequence described above—save for the option bot processing—is used toidentify drivers for event risk and transaction frequency. After allevent frequency models have been developed they are stored in the eventmodel table (158) and processing advances to software block 361.

The software in block 361 checks the measure layer table (145) andimpact model table (166) in the contextbase (50) to determine if impactmodels are current for all event risks and actions. If all impact modelsare current, then processing advances to a software block 370.Alternatively, if new impact models need to be developed, thenprocessing advances to a software block 335. The software in block 335retrieves information from the system settings table (162), the subjectschema table (157), the element layer table (141), the transaction layertable (142), the resource layer table (143), the relationship layertable (144), the environment layer table (149)), the reference layertable (154) and the impact model table (166) in order to completesummaries of impact history and forecasts before processing advances toa software block 305 where the processing sequence described above—savefor the option bot processing—is used to identify drivers for event riskand transaction impact (or magnitude). After impact models have beendeveloped for all event risks and action impacts they are stored in theimpact model table (166) and processing advances to a software block 370via software block 361.

The software in block 370 determines if adding spatial data improves theaccuracy of the predictive models. The software in block 370 uses avariable selection algorithm such as stepwise regression (other types ofvariable selection algorithms can be used) to combine the results fromeach type of prior analysis—with and without spatial data—to determinethe best set of variables for each type of analysis. The type ofanalysis having the smallest amount of error as measured by applying theroot mean squared error algorithm to the test data are used forsubsequent later analysis. Other error algorithms including entropymeasures may also be used. There are eight possible outcomes from thisanalysis as shown in Table 40.

TABLE 40 1. Best measure, event and impact models are spatial 2. Bestmeasure and event models are spatial, best impact model is not spatial3. Best measure and impact models are spatial, best event model is notspatial 5. Best measure models are spatial, best event and impact modelsare not spatial 5. Best measure models are not spatial, best event andimpact models are spatial 6. Best measure and impact models are notspatial, best event model is spatial 7. Best measure and event modelsare not spatial, best impact model is spatial 8. Best measure, event andimpact models are not spatialThe best set of models identified by the software in block 370 aretagged for use in subsequent processing before processing advances to asoftware block 371.

The software in block 371 checks the measure layer table (145) in thecontextbase (50) to determine if probabilistic relational models wereused in measure impacts. If probabilistic relational models were used,then processing advances to a software block 377. Alternatively, ifprobabilistic relational models were not used, then processing advancesto a software block 372.

The software in block 372 tests the performance drivers to see if thereis interaction between elements, factors and/or resources by entity. Thesoftware in this block identifies interaction by evaluating a chosenmodel based on stochastic-driven pairs of value-driver subsets. If theaccuracy of such a model is higher that the accuracy of statisticallycombined models trained on attribute subsets, then the attributes fromsubsets are considered to be interacting and then they form aninteracting set. Other tests of driver interaction can be used to thesame effect. The software in block 372 also tests the performancedrivers to see if there are “missing” performance drivers that areinfluencing the results. If the software in block 372 does not detectany performance driver interaction or missing variables for each entity,then system processing advances to a block 376. Alternatively, ifmissing data or performance driver interactions across elements, factorsand/resources are detected by the software in block 372 for one or moremeasures, processing advances to a software block 373.

The software in block 373 evaluates the interaction between performancedrivers in order to classify the performance driver set. The performancedriver set generally matches one of the six patterns of interaction: amulti-component loop, a feed forward loop, a single input driver, amulti-input driver, auto-regulation or a chain. After classifying eachperformance driver set the software in block 373 prompts the user (40)via the structure revision window (706) to accept the classification andcontinue processing, establish probabilistic relational models as theprimary causal model and/or adjust the specification(s) for the contextelements and factors in some other way in order to minimize or eliminateinteraction that was identified. For example, the user (40) can alsochoose to re-assign a performance driver to a new context element orfactor to eliminate an identified inter-dependency. After the optionalinput from the user (40) is saved in the element layer table (141), theenvironment layer table (149) and the system settings table (162),processing advances to a software block 374. The software in block 374checks the element layer table (141), the environment layer table (149)and system settings table (162) to see if there are any changes instructure. If there have been changes in the structure, then processingreturns to block 201 and the system processing described previously isrepeated. Alternatively, if there are no changes in structure, then theinformation regarding the element interaction is saved in therelationship layer table (144) before processing advances to a block376.

The software in block 376 checks the bot date table (163) anddeactivates vector generation bots with creation dates before thecurrent system date. The software in block 376 then initializes vectorgeneration bots for each context element, sub-context element, elementcombination, factor combination, context factor and sub-context factor.The bots activate in accordance with the frequency specified by the user(40) in the system settings table (162) and retrieve information fromthe element layer table (141), the transaction layer table (142), theresource layer table (143), the relationship layer table (144) and theenvironment layer table (149). Bots are independent components of theapplication software that complete specific tasks. In the case of vectorgeneration bots, their primary task is to produce vectors that summarizethe relationship between the causal performance drivers and changes inthe measure being examined. The vector generation bots use inductionalgorithms to generate the vectors. Other vector generation algorithmscan be used to the same effect. Every vector generation bot contains theinformation shown in Table 41.

TABLE 41 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.Measure 8. Context component or combination 9. Factor 1 . . . to 9 + n.Factor nWhen bots in block 376 have created and stored vectors for all timeperiods with data for all the elements, sub-elements, factors,sub-factors, resources, sub-resources and combinations that have vectorsin the subject schema table (157) by entity, processing advances to asoftware block 377.

The software in block 377 checks the bot date table (163) anddeactivates life bots with creation dates before the current systemdate. The software in block 377 then retrieves the information from thesystem settings table (162), the element layer table (141), thetransaction layer table (142), the resource layer table (143), therelationship layer table (144) and the environment layer table (149) inorder to initialize life bots for each element and factor. Bots areindependent components of the application software that completespecific tasks. In the case of life bots, their primary task is todetermine the expected life of each element, resource and factor. Thereare three methods for evaluating the expected life:

-   -   1. Elements, resources and factors that are defined by a        population of members or items (such as: channel partners,        customers, employees and vendors) will have their lives        estimated by forecasting the lives of members of the population        and then integrating the results into an overall population        density matrix. The forecast of member lives will be determined        by the “best” fit solution from competing life estimation        methods including the Iowa type survivor curves, Weibull        distribution survivor curves, growth models, Gompertz-Makeham        survivor curves, Bayesian population matrix estimation and        polynomial equations using the tournament method for selecting        from competing forecasts;    -   2. Elements, resources and factors (such as patents, long term        supply agreements, certain laws and insurance contracts) that        have legally defined lives will have their lives calculated        using the time period between the current date and the        expiration date of their defined life; and    -   3. Finally, elements, resources and factors that do not have        defined lives will have their lives estimated to equal the        forecast time period.        Every element life bot contains the information shown in Table        42.

TABLE 42 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.Measure 8. Context component or combination 9. Life estimation method(item analysis, defined or forecast period)After the life bots are initialized, they are activated in accordancewith the frequency specified by the user (40) in the system settingstable (162). After being activated, the bots retrieve information foreach element and sub-context element from the contextbase (50) in orderto complete the estimate of element life. The resulting values are thentagged and stored in the element layer table (141), the resource layertable (143) or the environment layer table (149) in the contextbase (50)before processing advances to a block 379.

The software in block 379 checks the bot date table (163) anddeactivates dynamic relationship bots with creation dates before thecurrent system date. The software in block 379 then retrieves theinformation from the system settings table (162), the element layertable (141), the transaction layer table (142), the resource layer table(143), the relationship layer table (144), the environment layer table(149) and the event risk table (156) in order to initialize dynamicrelationship bots for the measure. Bots are independent components ofthe application software that complete specific tasks. In the case ofdynamic relationship bots, their primary task is to identify the bestfit dynamic model of the interrelationship between the differentelements, factors, resources and events that are driving measureperformance. The best fit model is selected from a group of potentiallinear models and non-linear models including swarm models, complexitymodels, maximal time step models, simple regression models, power lawmodels and fractal models. Every dynamic relationship bot contains theinformation shown in Table 43.

TABLE 43 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.Measure 8. AlgorithmThe bots in block 379 identify the best fit model of the dynamicinterrelationship between the elements, factors, resources and risks forthe reviewed measure and store information regarding the best fit modelin the relationship layer table (144) before processing advances to asoftware block 380.

The software in block 380 checks the bot date table (163) anddeactivates partition bots with creation dates before the current systemdate. The software in the block then retrieves the information from thesystem settings table (162), the element layer table (141), thetransaction layer table (142), the resource layer table (143), therelationship layer table (144), the measure layer table (145), theenvironment layer table (149), the event risk table (156) and thescenarios table (168) to initialize partition bots in accordance withthe frequency specified by the user (40) in the system settings table(162). Bots are independent components of the application software ofthe present invention that complete specific tasks. In the case ofpartition bots, their primary task is to use the historical and forecastdata to segment the performance measure contribution of each element,factor, resource, combination and performance driver into a base valueand a variability or risk component. The system of the present inventionuses wavelet algorithms to segment the performance contribution into twocomponents although other segmentation algorithms such as GARCH could beused to the same effect. Every partition bot contains the informationshown in Table 44.

TABLE 44 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.Measure 8. Context component or combination 9. Segmentation algorithmAfter the partition bots are initialized, the bots activate inaccordance with the frequency specified by the user (40) in the systemsettings table (162). After being activated the bots retrieve data fromthe contextbase (50) and then segment the performance contribution ofeach element, factor, resource or combination into two segments. Theresulting values by period for each entity are then stored in themeasure layer table (145), before processing advances to a softwareblock 382.

The software in block 382 retrieves the information from the event modeltable (158) and the impact model table (166) and combines theinformation from both tables in order to update the event risk estimatefor the entity. The resulting values by period for each entity are thenstored in the event risk table (156), before processing advances to asoftware block 389.

The software in block 389 checks the bot date table (163) anddeactivates simulation bots with creation dates before the currentsystem date. The software in block 389 then retrieves the informationfrom the relationship layer table (144), the measure layer table (145),the event risk table (156), the subject schema table (157), the systemsettings table (162) and the scenarios table (168) in order toinitialize simulation bots in accordance with the frequency specified bythe user (40) in the system settings table (162).

Bots are independent components of the application software thatcomplete specific tasks. In the case of simulation bots, their primarytask is to run three different types of simulations of subject measureperformance. The simulation bots run probabilistic simulations ofmeasure performance using the normal scenario, the extreme scenario andthe blended scenario. They also run an unconstrained genetic algorithmsimulation that evolves to the most negative value possible over thespecified time period. In one embodiment, Monte Carlo models are used tocomplete the probabilistic simulation, however other probabilisticsimulation models such as Quasi Monte Carlo, genetic algorithm andMarkov Chain Monte Carlo can be used to the same effect. The models areinitialized using the statistics and relationships derived from thecalculations completed in the prior stages of processing to relatemeasure performance to the performance driver, element, factor, resourceand event risk scenarios. Every simulation bot activated in this blockcontains the information shown in Table 46.

TABLE 46 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: normal, extreme, blended orgenetic algorithm 6. Measure 7. Hierarchy or group 8. EntityAfter the simulation bots are initialized, they activate in accordancewith the frequency specified by the user (40) in the system settingstable (162). Once activated, they retrieve the specified information andsimulate measure performance by entity over the time periods specifiedby the user (40) in the system settings table (162). In doing so, thebots will forecast the range of performance and risk that can beexpected for the specified measure by entity within the confidenceinterval defined by the user (40) in the system settings table (162) foreach scenario. The bots also create a summary of the overall risksfacing the entity for the current measure. After the simulation botscomplete their calculations, the resulting forecasts are saved in thescenarios table (168) by entity and the risk summary is saved in thereport table (153) in the contextbase (50) before processing advances toa software block 390.

The software in block 390 checks the measure layer table (145) and thesystem settings table (162) in the contextbase (50) to see ifprobabilistic relational models were used. If probabilistic relationalmodels were used, then processing advances to a software block 398.Alternatively, if the current calculations did not rely on probabilisticrelational models, then processing advances to a software block 391.

The software in block 391 checks the bot date table (163) anddeactivates measure bots with creation dates before the current systemdate. The software in block 391 then retrieves the information from thesystem settings table (162), the measure layer table (145) and thesubject schema table (157) in order to initialize bots for each contextelement, context factor, context resource, combination or performancedriver for the measure being analyzed. Bots are independent componentsof the application software of the present invention that completespecific tasks. In the case of measure bots, their task is to determinethe net contribution of the network of elements, factors, resources,events, combinations and performance drivers to the measure beinganalyzed. The relative contribution of each element, factor, resource,combination and performance driver is determined by using a series ofpredictive models to find the best fit relationship between the contextelement vectors, context factor vectors, combination vectors andperformance drivers and the measure. The system of the present inventionuses different types of predictive models to identify the best fitrelationship: neural network, CART, projection pursuit regression,generalized additive model (GAM), GARCH, MMDR, MARS, redundantregression network, ODE, boosted Naïve Bayes Regression, relevancevector, hierarchical Bayes, Gillespie algorithm models, the supportvector method, markov, linear regression, and stepwise regression. Themodel having the smallest amount of error as measured by applying theroot mean squared error algorithm to the test data are the best fitmodel. Other error algorithms and/or uncertainty measures includingentropy measures may also be used. The “relative contribution algorithm”used for completing the analysis varies with the model that was selectedas the “best-fit”. For example, if the “best-fit” model is a neural netmodel, then the portion of the measure attributable to each input vectoris determined by the formula shown in Table 47.

TABLE 47$\left( {\underset{k = 1}{\overset{k = m}{Sum}}\mspace{14mu} \underset{j = 1}{\overset{j = n}{Sum}}\mspace{14mu} I_{jk}\mspace{11mu} X\mspace{11mu} {O_{k}/\underset{j = 1}{\overset{j = n}{Sum}}}\mspace{11mu} I_{ik}} \right)/{\underset{k = 1}{\overset{k = m}{Sum}}\left( {\underset{j = 1}{\overset{j = n}{Sum}}\mspace{14mu} I_{jk}\mspace{11mu} X\mspace{11mu} O_{k}} \right)}$Where I_(jk) = Absolute value of the input weight from input node j tohidden node k O_(k) = Absolute value of output weight from hidden node kM = number of hidden nodes N = number of input nodesAfter completing the best fit calculations, the bots review the lives ofthe context elements that impact measure performance. If one or more ofthe elements has an expected life that is shorter than the forecast timeperiod stored in the system settings table (162), then a separate modelwill be developed to reflect the removal of the impact from theelement(s) that are expiring. The resulting values for relativecomponent of context contributions to measure performance are thencalculated and saved in the subject schema table (157). If thecalculations are related to a commercial business then the value of eachcontribution will also be saved. The overall model of measureperformance is saved in the measure layer table (145). Every measure botcontains the information shown in Table 48.

TABLE 48 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.Measure 8. Context component or combinationAfter the measure bots are initialized by the software in block 391 theyactivate in accordance with the frequency specified by the user (40) inthe system settings table (162). After being activated, the botsretrieve information and complete the analysis of the measureperformance. As described previously, the resulting relativecontribution percentages are saved in the subject schema table (157) byentity. The overall model of measure performance is saved in the measurelayer table (145) by entity before processing advances to a softwareblock 392.

The software in block 392 checks the measure layer table (145) in thecontextbase (50) to determine if all subject measures are current. Ifall measures are not current, then processing returns to software block302 and the processing described above for this portion (300) of theapplication software is repeated. Alternatively, if all measure modelsare current, then processing advances to a software block 394.

The software in block 394 retrieves the previously stored values formeasure performance from the measure layer table (145) before processingadvances to a software block 395. The software in block 395 checks thebot date table (163) and deactivates measure relevance bots withcreation dates before the current system date. The software in block 395then retrieves the information from the system settings table (162) andthe measure layer table (145) in order to initialize a bot for eachentity being analyzed. bots are independent components of theapplication software of the present invention that complete specifictasks. In the case of measure relevance bots, their tasks are todetermine the relevance of each of the different measures to entityperformance and determine the priority that appears to be placed on eachof the different measures is there is more than one. The relevance andranking of each measure is determined by using a series of predictivemodels to find the best fit relationship between the measures and entityperformance. The system of the present invention uses several differenttypes of predictive models to identify the best fit relationship: neuralnetwork, CART, projection pursuit regression, generalized additive model(GAM), GARCH, MMDR, redundant regression network, markov, ODE, boostednaive Bayes Regression, the relevance vector method, the support vectormethod, linear regression, and stepwise regression. The model having thesmallest amount of error as measured by applying the root mean squarederror algorithm to the test data are the best fit model. Other erroralgorithms including entropy measures may also be used. Bayes models areused to define the probability associated with each relevance measureand the Viterbi algorithm is used to identify the most likelycontribution of all elements, factors, resources, projects, events, andrisks by entity. The relative contributions are saved in the measurelayer table (145) by entity. Every measure relevance bot contains theinformation shown in Table 49.

TABLE 49 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Hierarchy or group 6. Entity 7.MeasureAfter the measure relevance bots are initialized by the software inblock 395 they activate in accordance with the frequency specified bythe user (40) in the system settings table (162). After being activated,the bots retrieve information and complete the analysis of the measureperformance. As described previously, the relative measure contributionsto measure performance and the associated probability are saved in themeasure layer table (145) by entity before processing advances to asoftware block 396.

The software in block 396 retrieves information from the measure table(145) and then checks the measures for the entity hierarchy to determineif the different levels are in alignment. As discussed previously, lowerlevel measures that are out of alignment can be identified by thepresence of measures from the same level with more impact on subjectmeasure performance. For example, employee training could be shown to bea strong performance driver for the entity. If the human resourcesdepartment (that is responsible for both training and performanceevaluations) had been using only a timely performance evaluationmeasure, then the measures would be out of alignment. If measures areout of alignment, then the software in block 396 prompts the manager(41) via the measure edit data window (708) to change the measures byentity in order to bring them into alignment. Alternatively, if measuresby entity are in alignment, then processing advances to a software block397.

The software in block 397 checks the bot date table (163) anddeactivates frontier bots with creation dates before the current systemdate. The software in block 397 then retrieves information from theevent risk table (156), the system settings table (162) and thescenarios table (168) in order to initialize frontier bots for eachscenario. Bots are independent components of the application software ofthe present invention that complete specific tasks. In the case offrontier bots, their primary task is to define the efficient frontierfor entity performance measures under each scenario. The top leg of theefficient frontier for each scenario is defined by successively addingthe features, options and performance drivers that improve performancewhile decreasing risk to the optimal mix in resource efficiency order.The bottom leg of the efficient frontier for each scenario is defined bysuccessively adding the features, options and performance drivers thatdecrease performance while decreasing risk to the optimal mix inresource efficiency order. Every frontier bot contains the informationshown in Table 50.

TABLE 50 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Entity 6. Scenario: normal, extremeand blendedAfter the software in block 397 initializes the frontier bots, theyactivate in accordance with the frequency specified by the user (40) inthe system settings table (162). After completing their calculations,the results of all three sets of calculations (normal, extreme and mostlikely) are saved in the report table (153) in sufficient detail togenerate a chart like the one shown in FIG. 12 before processingadvances to a software block 398.

The software in block 398 takes the previously stored entity schema fromthe subject schema table (157) and combines it with the relationshipinformation in the relationship layer table (144) and the measure layertable (145) to develop the entity ontology. The ontology is then storedin the ontology table (152) using the OWL language. Use of the rdf(resource description framework) based OWL language will enable thecommunication and synchronization of the entities ontology with otherentities and will facilitate the extraction and use of information fromthe semantic web. The semantic web rule language (swrl) that combinesOWL with Rule ML can also be used to store the ontology. After therelevant entity ontology is saved in the contextbase (50), processingadvances to a software block 402.

Complete Context Service Propagation

The flow diagrams in FIG. 8A and FIG. 8B detail the processing that iscompleted by the portion of the application software (400) thatidentifies valid context space, identifies principles, integrates thedifferent entity contexts into an overall context, propagates a CompleteContext™ Service and optionally displays and prints management reportsdetailing the measure performance of an entity. Processing in thisportion of the application software (400) starts in software block 402.

The software in block 402 calculates expected uncertainty by multiplyingthe user (40) and subject matter expert (42) estimates of narrow system(4) uncertainty by the relative importance of the data from the narrowsystem for each function measure. The expected uncertainty for eachmeasure is expected to be lower than the actual uncertainty (measuredusing R² as discussed previously) because total uncertainty is afunction of data uncertainty plus parameter uncertainty (i.e. are thespecified elements, resources and factors the correct ones) and modeluncertainty (does the model accurately reflect the relationship betweenthe data and the measure). After saving the uncertainty information inthe uncertainty table (150) processing advances to a software block 403.

The software in block 403 retrieves information from the relationshiplayer table (144), the measure layer table (145) and the context frametable (160) in order to define the valid context space for the currentrelationships and measures stored in the contextbase (50). The currentmeasures and relationships are compared to previously stored contextframes to determine the range of contexts in which they are valid withthe confidence interval specified by the user (40) in the systemsettings table (162). The resulting list of valid frame definitionsstored in the context space table (151). The software in this block alsocompletes a stepwise elimination of each user specified constraint. Thisanalysis helps determine the sensitivity of the results and may indicatethat it would be desirable to use some resources to relax one or more ofthe established constraints. The results of this analysis are stored inthe context space table (151) before processing advances to a softwareblock 410.

The software in block 410 integrates the one or more entity contextsinto an overall entity context using the weightings specified by theuser (40) or the weightings developed over time from user preferences.This overall context and the one or more separate contexts arepropagated as a SOAP compliant Personalized Medicine System (100). Eachlayer is presented separately for each function and the overall context.As discussed previously, it is possible to bundle or separate layers inany combination. This information in the service is communicated to theComplete Context™ Suite (625), narrow systems (4) and devices (3) usingthe Complete Context™ Service Interface (711) before processing passesto a software block 414. It is to be understood that the system is alsocapable of bundling this the context information by layer in one or morebots as well as propagating a layer containing this information for usein a computer operating system, mobile operating system, networkoperating system or middleware application.

The software in block 414 checks the system settings table (162) in thecontextbase (50) to determine if a natural language interface (714) isgoing to be used. If a natural language interface is going be used, thenprocessing advances to a software block 420. Alternatively, if a naturallanguage interface is not going to be used, then processing advances toa software block 431.

The software in block 420 combines the ontology developed in prior stepsin processing with unsupervised natural language processing to provide atrue natural language interface to the system of the present invention(100). A true natural language interface is an interface that providesthe system of the present invention with an understanding of the meaningof the words as well as a correct identification of the words. As shownin FIG. 11, the processing to support the development of a true naturallanguage interface starts with the receipt of audio input to the naturallanguage interface (714) from audio sources (1), video sources (2),devices (3), narrow systems (4), a portal (11) and/or services in theComplete Context™ Suite (625). From there, the audio input passes to asoftware block 750 where the input is digitized in a manner that is wellknow. After being digitized, the input passes to a software block 751where it is segmented into phonemes using a constituent-context model.The phonemes are then passed to a software block 752 where they arecompared to previously stored phonemes in the phoneme table (170) toidentify the most probable set of words contained in the input. The mostprobable set of words are saved in the natural language table (169) inthe contextbase (50) before processing advances to a software block 756.

The software in block 756 compares the word set to previously storedphrases in the phrase table (172) and the ontology from the ontologytable (152) to classify the word set as one or more phrases. After theclassification is completed and saved in the natural language table(169), processing passes to a software block 757.

The software in block 757 checks the natural language table (169) todetermine if there are any phrases that could not be classified with aweight of evidence level greater than or equal to the level specified bythe user (40) in the system settings table (162). If all the phrasescould be classified within the specified levels, then processingadvances to a software block 759. Alternatively, if there were phrasesthat could not be classified within the specified levels, thenprocessing advances to a software block 758.

The software in block 758 uses the constituent-context model that usesword classes in conjunction with a dependency structure model toidentify one or more new meanings for the low probability phrases. Thesenew meanings are compared to known phrases in an external database (7)such as the Penn Treebank and the system ontology (152) before beingevaluated, classified and presented to the user (40). Afterclassification is complete, processing advances to software block 759.

The software in block 759 uses the classified input and ontology togenerate a response (that may include the completion of actions) to thetranslated input and generate a response to the natural languageinterface (714) that is then forwarded to a device (3), a narrow system(4), an external service (9), a portal (11), an audio output device (12)or an service in the Complete Context™ Suite (625). This processcontinues until all natural language input has been processed. When thisprocessing is complete, processing advances to a software block 431.

The software in block 431 checks the system settings table (162) in thecontextbase (50) to determine if services or bots are going to becreated. If services or bots are not going to be created, thenprocessing advances to a software block 433. Alternatively, if servicesor bots are going to be created, then processing advances to a softwareblock 432.

The software in block 432 supports the development interface window(712) that supports four distinct types of development projects by theComplete Context™ Programming System (610):

-   -   1. the development of extensions to Complete Context™ Suite        (625) in order to provide the user (40) with the specific        information for a given user requirement;    -   2. the development of Complete Context™ Bots (650) to complete        one or more actions, initiate one or more actions, complete one        or more events, respond to requests for actions, respond to        actions, respond to events, obtain data or information and        combinations thereof. The software developed using this option        can be used for software bots or agents and robots;    -   3. programming devices (3) with rules of behavior for different        contexts that are consistent with the context frame being        provided—i.e. when in church (reference layer location) do not        ring unless it is the boss (element) calling; and    -   4. the development of new context aware services.        The first screen displayed by the Complete Context™ Programming        System (610) asks the user (40) to identify the type of        development project. The second screen displayed by the Complete        Context™ Programming System (610) will depend on which type of        development project the user (40) is completing. If the first        option is selected, then the user (40) is given the option of        using pre-defined patterns and/or patterns extracted from        existing narrow systems (4) to modify one or more of the        services in the Complete Context™ Suite (625). The user (40) can        also program the service extensions using C++ or Java with or        without the use of patterns.

If the second option is selected, then the user (40) is shown a displayof the previously developed entity schema (157) for use in defining anassignment and context frame for a Complete Context™ Bot (650). Afterthe assignment specification is stored in the bot assignment table(167), the Complete Context™ Programming System (610) defines aprobabilistic simulation of bot performance under the three previouslydefined scenarios. The results of the simulations are displayed to theuser (40) via the development interface window (712). The CompleteContext™ Programming System (610) then gives the user (40) the option ofmodifying the bot assignment or approving the bot assignment. If theuser (40) decides to change the bot assignment, then the change inassignment is saved in the bot assignment table (167) and the processdescribed for this software block is repeated. Alternatively, if theuser (40) does not change the bot assignment, then Complete Context™Programming System (610) completes two primary functions. First, itcombines the bot assignment with results of the simulations to developthe set of program instructions that will maximize bot performance underthe forecast scenarios. The bot programming includes the entity ontologyand is saved in the bot assignment table (167). In one embodiment Prologis used to program the bots. Prolog is used because it readily supportsthe situation calculus analyses used by the Complete Context™ Bots (650)to evaluate their situation and select the appropriate course of action.Each Complete Context™ Bot (650) has the ability to interact with botsand entities that use other schemas or ontologies in an automatedfashion.

If the third option is selected, then the previously information aboutthe context quotient for the device (3) is developed and used to selectthe pre-programmed options (i.e. ring, don't ring, silent ring, etc.)that will be presented to the user (40) for implementation. The user(40) will also be given the ability to construct new rules for thedevice (3) using the parameters contained within the device-specificcontext frame.

If the fourth option is selected, then the user (40) is given apre-defined context frame interface shell along with the option of usingpre-defined patterns and/or patterns extracted from existing narrowsystems (4) to develop a new service. The user (40) can also program thenew service completely using C# or Java.

When programming is complete using one of the four options, processingadvances to a software block 433. The software in block 433 prompts theuser (40) via the report display and selection data window (713) toreview and select reports for printing. The format of the reports iseither graphical, numeric or both depending on the type of report theuser (40) specified in the system settings table (162). If the user (40)selects any reports for printing, then the information regarding theselected reports is saved in the report table (153). After the user (40)has finished selecting reports, the selected reports are displayed tothe user (40) via the report display and selection data window (713).After the user (40) indicates that the review of the reports has beencompleted, processing advances to a software block 434. The processingcan also pass to block 434 if the maximum amount of time to wait for noresponse specified by the user (40) in the system settings table isexceeded before the user (40) responds.

The software in block 434 checks the report table (153) to determine ifany reports have been designated for printing. If reports have beendesignated for printing, then processing advances to a block 435. Itshould be noted that in addition to standard reports like a performancerisk matrix and the graphical depictions of the efficient frontier shown(FIG. 12), the system of the present invention can generate reports thatrank the elements, factors, resources and/or risks in order of theirimportance to measure performance and/or measure risk by entity, bymeasure and/or for the entity as a whole. The system can also producereports that compare results to plan for actions, impacts and measureperformance if expected performance levels have been specified and savedin appropriate context layer. The software in block 435 sends thedesignated reports to the printer (118). After the reports have beensent to the printer (118), processing advances to a software block 437.Alternatively, if no reports were designated for printing, thenprocessing advances directly from block 434 to block 437. The softwarein block 437 checks the system settings table (162) to determine if thesystem is operating in a continuous run mode. If the system is operatingin a continuous run mode, then processing returns to block 205 and theprocessing described previously is repeated in accordance with thefrequency specified by the user (40) in the system settings table (162).Alternatively, if the system is not running in continuous mode, then theprocessing advances to a block 438 where the system stops.

Thus, the reader will see that the system and method described abovetransforms data, information and knowledge from disparate devices (3)and narrow systems (4) into a Personalized Medicine System (100). Thelevel of detail, breadth and speed of the analysis gives users of thePersonalized Medicine System (100) the ability to create context andapply it to solving real world health problems in an fashion that isuncomplicated and powerful.

While the above description contains many specificities, these shouldnot be construed as limitations on the scope of the invention, butrather as an exemplification of one embodiment thereof. Accordingly, thescope of the invention should be determined not by the embodimentillustrated, but by the appended claims and their legal equivalents.

1. A personalized medicine method, comprising: preparing data from aplurality of subject related systems for use in processing, defining asubject using at least a portion of said data and a plurality of userinput, analyzing said data as required to define and store a causalpredictive model for one or more health function measures of saidsubject, and using one or more automated analyses of said causalpredictive model to complete activities selected from the groupconsisting of customizing a treatment, customizing a test, ordering atreatment, ordering a test, forecasting a sustainable longevity,analyzing the impact of user specified changes on a subject performance,customizing information for the subject, customizing a product or aservice for the subject, displaying a graph about subject performance,exchanging an element with one or more subjects or entities in anautomated fashion, forecasting one or more future values of subjectrelated variables, identifying one or more metrics and rules formonitoring subject performance, identifying one or more changes thatwill optimize subject performance on one or more function measures,quantifying one or more risks to a subject function measure performance,quantifying an impact of surprises on subject performance, simulating asubject performance, establishing one or more priorities for subjectactions and commitments, establishing an expected performance level forthe subject, reviewing a subject performance using user definedmeasures, identifying a data and information combination that is mostrelevant to the subject, identifying one or more subject preferences,loading a data and information combination that is most relevant to thesubject into a cache, and creating a summary of subject context
 2. Themethod of claim 1, wherein a causal predictive model for one or morehealth measures of a subject comprises two or more aspects of a completecontext for a health of said subject selected from the group consistingof a reference frame context, a resource context, an element context, anenvironment context, a measure context, a lexical context, arelationship context, a transaction context and combinations thereof. 3.The method of claim 2, wherein a causal predictive model for one or morehealth measures of a subject and the two or more aspects of a completecontext comprise a context frame.
 4. The method of claim 1, wherein asubject is a patient, two or more patients or a patient-entity system.5. The method of claim 1, wherein a set of useful activities furthercomprise developing one or more programs for subject related devices,creating a true natural language interface for the subject anddeveloping one or more subject related software programs.
 6. The methodof claim 1, wherein a causal predictive model for one or more healthmeasures of a subject comprises an impact of one or more functions ofone or more biological entities associated with said subject, and wherea biological entity is selected from the group consisting ofmacromolecular complex, protein, rna, dna, methylation, gene, organelle,cell, monomer, dimer, large oligomer, aggregate and particle.
 7. Meansfor completing the method of claim 1 and a plurality of narrow systems.8. A program storage device readable by a computer, tangibly embodying aprogram of instructions executable by a computer to perform method stepsfor performing a personalized medicine method, comprising: preparingdata from a plurality of subject related systems for use in processing,defining a subject using at least a portion of said data and a pluralityof user input, analyzing said data as required to define and store acausal predictive model for one or more health function measures of saidsubject, and using one or more automated analyses of said causalpredictive model to complete activities selected from the groupconsisting of customizing a treatment, customizing a test, ordering atreatment, ordering a test, forecasting a sustainable longevity,analyzing the impact of user specified changes on a subject performance,capturing a subject related knowledge from one or more subject matterexperts, customizing information for the subject, customizing a productor a service for the subject, displaying a graph about subjectperformance, exchanging an element with one or more subjects or entitiesin an automated fashion, forecasting one or more future values ofsubject related variables, identifying one or more metrics and rules formonitoring subject performance, identifying one or more changes thatwill optimize subject performance on one or more function measures,quantifying one or more risks to a subject function measure performance,quantifying an impact of surprises on subject performance, simulating asubject performance, establishing one or more priorities for subjectactions and commitments, establishing an expected performance level forthe subject, reviewing a subject performance using user definedmeasures, identifying a data and information combination that is mostrelevant to the subject, identifying one or more subject preferences,loading a data and information combination that is most relevant to thesubject into a cache, and creating a summary of subject context.
 9. Theprogram storage device of claim 8, wherein a causal predictive model forone or more health measures of a subject comprises two or more aspectsof a complete context for a health of said subject selected from thegroup consisting of a reference frame context, a resource context, anelement context, an environment context, a measure context, a lexicalcontext, a relationship context, a transaction context and combinationsthereof.
 10. The method of claim 2, wherein a causal predictive modelfor one or more health measures of a subject and the two or more aspectsof a complete context comprise a context frame.
 11. The program storagedevice of claim 8, wherein a subject is a patient, two or more patientsor a patient-entity system.
 12. The program storage device of claim 8,wherein a set of useful activities further comprise developing one ormore programs for subject related devices, creating a true naturallanguage interface for the subject and developing one or more subjectrelated software programs.
 13. The method of claim 1, wherein a causalpredictive model for one or more health measures of a subject comprisesan impact of one or more functions of one or more biological entitiesassociated with said subject, and where a biological entity is selectedfrom the group consisting of macromolecular complex, protein, rna, dna,methylation, gene, organelle, cell, monomer, dimer, large oligomer,aggregate and particle.
 14. The program storage device of claim 8,wherein the computer readable medium further comprises a plurality ofbots or intelligent agents.
 15. A system for personalized medicine,comprising: a computer with a processor having circuitry to executeinstructions; a storage device available to said processor withsequences of instructions stored therein, which when executed cause theprocessor to: prepare data from a plurality of subject related systemsfor use in processing, define a subject using at least a portion of saiddata and a plurality of user input, analyze at least a portion of saiddata as required to define and store a causal predictive model for oneor more health function measures of said subject, and using one or moreautomated analyses of said causal predictive model to complete usefulactivities selected from the group consisting of customizing atreatment, customizing a test, ordering a treatment, ordering a test,forecasting a sustainable longevity, analyzing the impact of userspecified changes on a subject performance, capturing a subject relatedknowledge from one or more subject matter experts, customizinginformation for the subject, customizing a product or a service for thesubject, displaying a graph about subject performance, exchanging anelement with one or more subjects or entities in an automated fashion,forecasting one or more future values of subject related variables,identifying one or more metrics and rules for monitoring subjectperformance, identifying one or more changes that will optimize subjectperformance on one or more function measures, quantifying one or morerisks to a subject function measure performance, quantifying an impactof surprises on subject performance, simulating a subject performance,establishing one or more priorities for subject actions and commitments,establishing an expected performance level for the subject, reviewing asubject performance using user defined measures, identifying a data andinformation combination that is most relevant to the subject,identifying one or more subject preferences, loading a data andinformation combination that is most relevant to the subject into acache, and creating a summary of subject context.
 16. The system ofclaim 15, wherein a causal predictive model for one or more healthmeasures of a subject comprises three or more aspects of a completecontext for a health of said subject selected from the group consistingof a reference frame context, a resource context, an element context, anenvironment context, a measure context, a lexical context, arelationship context, a transaction context and combinations thereof.17. The system of claim 15, wherein a causal predictive model for one ormore health measures of a subject and the two or more aspects of acomplete context comprise a context frame.
 18. The system of claim 15,wherein a subject is a patient, two or more patients or a patient-entitysystem.
 19. The system of claim 15, wherein a set of useful activitiesfurther comprise developing one or more programs for subject relateddevices, creating a true natural language interface for the subject anddeveloping one or more subject related software programs.
 20. The systemof claim 15, wherein a causal predictive model for one or more healthmeasures of a subject comprises an impact of one or more functions ofone or more biological entities associated with said subject, and wherea biological entity is selected from the group consisting ofmacromolecular complex, protein, rna, dna, methylation, gene, organelle,cell, monomer, dimer, large oligomer, aggregate and particle.